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Enterprise JavaBeans are easy, well, at least when you compare ejb 

o what you’d have to do to write your own scalable, transactional, secure, persistent, 
concurrent enterprise component server. In this chapter, we’ll develop, deploy, and run an 
EJB application, and then dive into the details. Before we’re done, we’ll look at the use, 
benefits, and characteristics of EJB, and we’ll look (briefly) at how EJB containers work. 
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What is EJB all about? 

No more vendor lock-in! 

How does it all work? 

Behind the scenes... 
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The Advice Guy bean 

Five things you do to build a bean 
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(the remote 
component 
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EJB Architecture 

EJB is about infrastructure. Your components are the building blocks. With 
EJB, you can build big applications. The kind of applications that could run everything 
from the Victoria’s Secret back-end to document-handling systems at CERN. But an 
architecture with this much flexibility, power, and scalability isn’t simple. It all begins with a 
distributed programming model... 


(J2EE API) 


«interface» 

Enfe/p/vseSean 


no methods 


(J2EE API) 


《 interface 》 

SessionBean 


//several methods 


YOU write this 
— class 

(the bean class) 
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removeBook() 
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Exposing Yourself 

You can’t keep your bean private. Clients need to see what you ve got 
(Except for message-driven beans, which don’t have a client view). The Advice Bean 
exposes the getAdvice() method in its Component interface — the place where you declare 
business methods. But that’s not all the client sees. Remember, the Advice interface 
extends EJBObject, an interface with methods of its own. Methods the client can see. 
Methods the client can call. And it works the same way with the Home interface. 



Stateless 
beans 




For stateless session beans from 
the same home, isldentical() always 
returns true, even for different beans. 
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Arguments to Remote vs. local methods 
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Being a Session Bean 

Session beans are created and removed, if you re lucky, you re a 
stateless bean. Because the life of a stateful bean is tied to the whims of a heartless 


client. Stateful beans are created at the client’s insistence, and live and die only to serve 
that one client. But ahhhh, the life of a stateless bean is fabulous! Pools, those little 
umbrella drinks, and no boredom since you get to meet so many different clients. 
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Container callbacks, for the special moments in a bean’s life 
Bean Creation 

Bean things you can do within business methods 
Passivation: a stateful bean’s chance at scalability 
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SessionGontext: you need it more than it needs you 
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If you've got any last 
words, you better do 
it in your ejbRemove()... 


Entities are Persistent 

^ Entity beans persist. Entity beans exist. Entity beans are. They are object 
representations of something in an underlying persistent store. (Think: database, 
because most entity beans represent something from a relational database.) If you have 
a Customer entity bean, then one bean might represent the entity Tyler Durden, ID #343, 
while another is the entity Do 门门 y Darko, ID #42. Three beans, representing three real 
entities. An entity bean is simply a realization of something that already exists. 



Exam objectives 
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Entity beans from the client’s point of view 
A very simple Customer entity bean 
Entity bean Remote component interface 
Entity bean Remote home interface 

What does the client really want from an entity bean home? 

Home business methods to the rescue 

Session bean createO vs. entity bean createO 

Session bean remove() vs. entity bean removeO 

Entity/bean/instance death 
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Being an Entity Bean 

Entity beans are actors. As long as they’re alive, they’re either in the pool or 
they’re being somebody. Somebody from the underlying persistent store (an entity from 



the database). When a bean is playing a part, the bean and the underlying entity have to 
stay in sync. Imagine the horror if the bean is pretending to be, say, Audrey Leone, and 
someone lowers Audrey’s credit limit in the database... but forgets to tell the bean. 



doStuff(myContext.getEJBObject()) 
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When Beans Relate 

Entity beans need relationships. An Order needs a Customer. A Lineltem 
needs an Order. An Order needs Lineltems. Entity beans can have container-managed 


relationships (CMR) and the Container takes care of virtually everything. Make a new 
Lineltem that’s related to an Order? If you ask the Customer to show you his Orders, 


you’ll see the new Lineltem. Best of all, you can use EJB-QL to write portable queries. 


Multiplicity: 
many 


Multiplicity: 
one 


Movie 

|X 

/ 

Director 

Director getDirector() 

0"* 
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Collection getMovies() 
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Getting the Message 

It’S fun to receive messages. Not as much fun as, say, getting that eBay 
package with the genuine Smurf™ lamp, but fun and efficient nonetheless. Imagine if 


you sent your order to eBay, and you couldn’t leave your house until the package was 


«interface» 

EJBContext 


getCailerPrincipal() 


delivered. That’s what it’s like with Session and Entity beans. But with message-driven 
beans, the client can send a message and walk away. 


getEJBHomeQ 

isCallerinRole(String s) 

getRollbackOnly() 

getEJBLocalhiome() 

getUserTransaction() 

setRollbackOnly() 


《 interface 》 

MessageDrivenContext 

//this interface adds no 
//new methods 
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The Atomic Age 

Transactions protect you. With transactions, you can try something knowing 
that if anything goes wrong along the way, you can just pretend the whole thing didn’t 
happen. Everything goes back to the way it was before. Transactions in EJB are a thing 


of beauty — you can deploy a bean with customized transaction behavior without touching 
the bean’s source code! But you can write transaction code, if you need to. 
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setRollbackOnlyO lives in TWO interfaces 

BMT can be a really BAD idea. BMT hurts bean reuse 

Container-managed transactions 

How attributes work 

Methods you MUST mark with an attribute (for a GMT bean) 
“Unspecified Transaction Context” 

DD example for GMT 


SessionSynchronization “special moments” 
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When Beans Go Bad 

Expect the unexpected. Despite your best efforts, things can go wrong. 

Terribly, tragically, wrong. You need to protect yourself. You can’t let your entire program 
collapse, just because one bean in the family throws an exception. The application must 
go on. You can’t prevent tragedy, but you can prepare for it. You need to know what is 
and is not recoverable, and who is responsible when a problem occurs. 
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A A Protect Your Secrets 

I I Keep your secrets. Security is about authentication and authorization. First, 

you have to prove your identity, and then we’ll tell you what you’re allowed to do. Security 
is easy in EJB, because you’re only dealing with authorization. You decide who gets to 
call which methods on your beans. Except one problem... if you’re a Bean Provider or App 
Assembler, you probably don’t know who the users are going to be! 


In the EJB 

In a vendor- 

In a company- 

Deployment 

specific way 

specific way 

Descriptor 

< security-role - ref > < security-role > 

飞 r 

users and groups 

real people 
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Security context propagation with <run-as> 
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The Joy of Deployment 

You worked hard on that bean. You coded, you compiled, you tested. About 
a hundred zillion times. The last thing you want to touch is already-tested source code, 


just because something simple changed in the deployment configuration. And what if you 
don’t even have the source code? EJB supports bean reuse through the customizable 
Deployment Descriptor and a bean’s special environment 


ejb-jar 
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The final Coffee Cram Mock Exam. This is it. 70 questions.The tone, topics, 

and difficulty level are virtually identical to the real exam. We know. 
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1 intro to EJB 木 

♦ Welcome to EJB ♦ 



Vou're gonna love 
EJB! And boy won't Jim and 
Betty be envious when your 
enterprise back-end is bigger 
than theirs... you might even 
get that promotion! 〆 


Enterprise JavaBeanS are easy. Well，at least when you compare EJB to what 
you’d have to do to write your own scalable, transactional, secure, concurrent enterprise 
server. In this chapter, we’ll develop, deploy, and run an EJB application, before diving 
into the details. Before we’re done, we’ll look at the use, benefits, and characteristics of 
EJB, and we’ll look (briefly) at how EJB containers work. We’ll take a high-level look at the 
architecture of EJB and learn about the three bean types. The more you understand from 
this chapter, the less you’ll have to memorize later, so don’t skip it. (If you’re an EJB expert, 
you can probably get away with just a quick skim.) 


this is a new chapter 


1 



exam objectives 
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1.1 Identify the use, benefits, and 
characteristics of Enterprise 
Javabeans technology, for version 2.0 
of the EJB specification. 


You need to know how EJB works overall, 
what it’s good for, what it provides, and 
what it doesn’t provide. 

You need to understand the overall 
architecture of EJB and how that 
architecture supports the features of EJB. 
For example, you need to know that 
EJB supports transactions, security, and 
concurrency, but it does not guarantee 
load-balancing, fail-over, or clustering. You 
need to know that EJB supports three 
bean types: session, entity, and message- 
driven, and that session beans can be 
stateless or stateful. 
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intro to EJB 


What is EJP all about? 


Component-based development 

With enterprise j avabeans, you can develop building 
blocks — EJB components — that you or someone else can 
assemble and reassemble into different applications. 

For example, you might create a Customer bean ( bean is 
another word for component) that represents a customer 
in a database. You can use that Customer bean in an 
accounting program, an e-commerce shopping cart 
system, a tech support application, or virtually any other 
application that might need to represent a customer. 

In fact, with some beans, the bean developer and the 
application assembler might not work for the same 
company or have any knowledge of one another. 

If you’re a bean developer, you might build an Order 
bean, or a Payroll bean, or a ShoppingCart bean that 
developers in some unrelated company can buy and use 
to construct their own custom applications. 

One beauty of component-based development is that 
you take code reuse to a whole new level. Instead of 
reusing Java classes, you get to reuse a bigger chunk of 
functionality. Often, you can modify the way a bean 
works without ever touching its Java code!Yo\\W learn in 
this chapter that when you deploy a bean into a server, 
you can configure and customize the bean declaratively — 
through an XML-based deployment descriptor — to change 
the way the bean behaves at runtime. 

Witk component-liasect ctevelopment, 
you take cocte reuse to a wkole new 
level. Witk 00 development, you reuse 
classes，Wt witk components, you 
reuse a er ckunk ol functionality, 
and you can customize tkem witkout 
toucliingf cocie! 



Application A ： online shopping 

Fred assembles an online shopping 
application using two components he 
bought from Beans-R-Us, plus a third 
component Fred developed at his 
company. 


V)VA»\*b 





Customer 
component l 




Support 
component 





Inventory 

component 


Bill 

"these -two 


Order 
component 


Application B ： technical support 

Bill assembles a technical support app 
using two components he bought from 
Beans-R-Us, plus two components he 
developed himself. 


you are here ► 
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benefits of EJB 


What does W really give me? 


EJB lets you focus on the business logic 
for your business，and leave the underlying 
services (transactions ， networking ， 
security ， etc.) to the EJB server vendor. 


EJB servers give you a bunch 
of services, so that you don’t 
have to write them yourself: 


Imagine you work for Guitar Land, a company that sells 
musician’s gear online. You have better things to do than 
work 90 hours a week, so where would you want to spend your 
time? Wouldn’t you rather concentrate on how Guitar Land 
does business online, as opposed to writing your own secure, 
networked, transaction management server? Why not work 
on what you know best (business logic for your particular 

business), and leave the heavy lifting (i.e. 
the big infrastructure services you get 
from the server) to someone else? 

The EJB model is to let everyone do 
what they do best — the server vendors 
concentrate on the infrastructure that most 
enterprise applications need, while the 
business developers concentrate on their own 
business logic. 

EJB let’s you customize and 
configure reusable components at 
deploy-time, without touching the 
source code! 

You can change the way a bean uses the 
underlying services simply by tweaking an XM1 document 
at deploy-time. For example, you can completely define the 
security access control for a bean’s methods within XML 
(declaratively) rather than within the bean’s source code 
(programmatically). And you can customize the way a bean’s 
methods run in transactions, all within the deployment 
descriptor, without having to hard-code in transaction 
boundaries and behaviors. That just rocks. 



+ Transaction management 


Security 


+- Concurrency 


+ Networking 


-+■ Resource management 


+ Persistence 


+ Messaging 


+ Deploy-time customization 
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Aor 


No more vendor lock-in! 


Enterprise beans are portable — 
not just to different JVM% but 
to different EJB servers. 

One of the reasons we all love Java is its 
portability across multiple platforms. The whole 
write-once-run-anywhere (WORA) thing. 

EJB takes portability to a new level, instead of 
write-once-mn-anywhere, it’s write-once-deploy- 
anywhere (WODA). Just as WORA frees you 
from being forced to work on a single OS, 
WODA frees you from being at the mercy of 
your application server vendor. And then of 
course there’s YODA, but we digress. 

In the old days, each application server vendor 
had its own proprietary API. You learn it, work 
with it, and finally get your enterprise apps up 
and running. And then guess what? You need a 
new feature. And then guess what? Your vendor 
says, “We’re considering that for Q3... of next 
year”. Now what? Like a drug dealer, they’ve 
hooked you, and now it’s just too painful to 
consider giving them up. Give them up for 
what? Another vendor and another proprietary 
API and more lock-in. 


Instead of learning 
a new API for each app server, 
with EJB, I only learn ONE, and my 
components will work on any EJB server. 
Those vendors are gonna have to suck up 
to ME for a change... 


One of the crucial benefits of EJB is WODA. 
And now the vendors have to compete not just 
to sell you in the first place, but to keep you. 
Because as everybody knows, you can just pack 
up your beans and go elsewhere. 



you are here ► 
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EJB questions 


What's the difference 
between EJB and J2EE? 

Both J2EE and EJB are 
specifications for a server. But EJB 
is actually a subset of J2EE. In other 
words, a J2EE server must include 
an EJB container. We’ve used the 
word server on these first pages, but 
technically, the thing that enterprise 
javabeans run in is called an EJB 
container. So, every J2EE server must 
include an EJB container (along 
with a Web container that can run 
servlets and JSPs). 

This exam is about the EJB portion 
of J2EE, whereas the SCWCD exam 
(Sun Certified Web Component 
Developer) is about the Web portion 
of J2EE. 

Later in this chapter, we’ll get more 
into the details of how J2EE and EJB 
fit together. 

For the rest of this book, we use 
the terms EJB server, container, 
and server interchangeably. If the 
difference between the terms 
matters, we’ll make it clear. 


^JiereiarejiP 

Dumb Questions 

What's the difference 
between regular javabeans and 
enterprise javabeans? 


Can I use EJB components 
without an EJB-compliant app 
server? 


n: Nope. EJB components can’t 
live outside of an EJB container.They 
don’t have a main method, and even 
if you add one to your bean class, 
the bean wouldn’t be very useful 
on its own. Most of the methods in 
an enterprise bean are called by the 
container itself and have no meaning 
outside the server. Remember, the 
whole point of an EJB server is to 
give you all the big services (security, 
transactions, etc.), and without the 
server, you’d lose everything but 
your basic business logic. And if that 
business logic relies on the container 
(for example,calling methods 
on interfaces provided by the 
container), then even the business 
logic would fail. 

Can I design and write my 
code in such a way that most of 
the business logic is in a plain old 
Java class, and just have the bean 
call methods on that class? That 
way I could still reuse the business 
logic... 

A- 

Yes, you can do that, and in 
fact a lot of designers write separate 
non-bean, reusable classes and then 
have the beans invoke methods 
on those classes. If your bean calls 
a method on a non-bean Java 
class,that method is still under the 
control of the container, so as far 
as the container is concerned, that 
non-bean method is just part of the 
bean's functionality. 


n: Congratulations! You’re the 3 
millionth person to have asked that 
question. 

The term "javabean” means a 
reusable component. Regular old 
non-enterprise beans (and beans is 
just a shorter form of javabeans), are 
reusable components that follow a 
naming convention that can be used 
by development tools. 

By far, the most common type of 
javabean is any GUI component (like 
a Swing button or text field). Nearly 
all Java IDEs are javabean-compliant, 
so that if you’re working in a visual 
layout tool you can click on a button 
and up pops a property sheet where 
you can set the color, size, font, etc. 
The tool knows which properties the 
bean has because the bean follows 
conventions for getters and setters. 

But regular javabeans aren’t just 
for GUI components — other Java 
technologies, including Jini and 
Servlets, can use javabean features. 

Enferpr/se javabeans are also 
reusable components, but that’s 
where the similarity ends.The'bean' 
part of a regular javabean is used 
mostly at development-time, as a 
way to ease or speed up hooking 
one bean’s events to another bean’s 
methods, or setting property values 
(which often mean the same thing 
as instance variable values). A regular 
bean runs in a JVM, just like any 
other normal Java class. But the 
"bean” part of an enterprise bean 
kicks in at runtime, and an enterprise 
bean must be run under the control 
of an EJB container. 
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For the rest of the book, when we 
say bean, we mean enterprise bean. 


intro to EJB 
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How does it all work? 

Your beans run under the control (and protection) 
of the EJB server. 

The server steps into the middle of every 
method call from a client to a bean and inserts 
the “services” like security ， transactions, and 
persistence. 

Your beans live and run in the server, and the server does virtually 
everything to manage transactions, security, persistence, and even the life 
and death of your objects. And it does all this by stepping in each time 
a client makes a request (i.e. calls a business method on the bean). The 
server jumps in and starts asking questions like: 

“Does this client have security clearance to call this method ?or 

“Does this bean need to run as part of a larger transaction ?or 

“Does this bean need to refresh itself with data from the database, before running 
that method for the client?” 



A ridiculously high-level view of EJB architecture 


you are here ► 
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what real! happens 


behind the scenes 



Client 


L Not so fast buddy. K 

Nobody, but NOBODY, talks to ^ 
the bean except the container. If you 
want the bean, you gotta go through me 
Show me some ID, and I'll check with 
the container, and if ifs OK, I’ll ) 


pass on your request. 



Container 
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intro to EJB 


I need a Broker bean 
down here now. Slim Sleazy 
needs to make a trade. Oh, and 
make sure the bean gets his own 
new transaction. 


What do you mean 
there's no bean? Just 
get one from the freakin' pool! No, 
it doesn't matter which one. Yes, I 
KNOW the beans are spoiled little 
prima donnas, but they ARE the stars 
of the show right now. 


4 " 




Container 



Container 


Hey, I went last 
time, so one of you can 
go now. Besides, I*m still 
recovering from that big 
transaction rollback. 


O 


They SO don’t pay 
us enough for this. 

Were the ones who do the REAL 
business logic. But at least we 
never have to talk to the clients. 
Yeah, havin an EJBObject 
bodyguard is pretty 
cool. 


OK, the bean is ready, 
so go ahead and pass 
the client's method request to 
the bean. And by the way, you can 
tell little miss u bean queen” she 
better shape up. I instantiated 
her, and I can send her to the 
garbage collector. 




o 


❼ 


the Bean Pool 



Container 
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EJB architecture 


jharpen your pencil 


① Label the three parts in the diagram. 



② Describe (briefly) what each of the three things are 
responsible for, or how they behave. 


A 



C 


: 


3 0 DM-J3 +-U! ziq 
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intro to EJB 


Peaws come iw three flavors 



Entity 

Use an entity bean to represent a thing in a 
persistent store. That almost always means 
something in a database, where an instance 
of an entity bean represents a row in a table 
(although if the database is normalized, the 
bean might be drawing from rows in multiple 
tables). A typical entity example is Customer, 
where one entity might represent Bo Olean 
(ID# 343) and another entity might represent 
Trixia Lin (ID# 870). 



Customer 。。 Inventory 

Bean 

Bean 


Customer 

Bean 



i ■ 一 


Message-driven 

Use a message-driven bean only when you 
need aJMS consumer. In other words, a bean 
that can listen for messages from a JMS messaging 
service. Clients never call message-driven 
beans directly; in order to get a message- 
driven bean to do something, a client must 
send a message to a messaging service. 

That means a message-driven bean has no 
EJBObject because the server gets the client 
requests directly from a messaging service 
rather than as a call from the client to the 


I’m waiting for 
announcements about 
new customers. 


NewCustomerListener 

Bean 


I’m waiting for a 
big calculation job 
to be posted. 

BigCalcJobListener 
Bean 


bean. A typical message-driven bean might 
be a NewCustomerNotification subscriber. 



Session 

Use a session bean for... everything else. 
Almost any kind of back-end service can 
(and often should) begin with a session bean. 
Where an entity bean represents a thing, a 
session bean typically represents a process. To 
put it another way, when you think of entity 
beans, think noun, and when you think of 
session beans, think verb. A shopping session 
is a typical example of a session bean, while 
a credit card processing system might be 
another session bean. 





Cart Bean 
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stateful and stateless session beans 


Session beans can be stateless 
or stateful 

We’ll go over all this in detail in the Session Bean 
chapter. For now, you need to know that session 
beans can be marked (at deployment time) as 
either stateor state/w/. 

A stateful bean can remember conversational state 
between method calls, while a stateless bean won’t 
remember anything about the client between 
method invocations. 


The phrase “conversational state” really means 
“client-specific state”，and a typical example is 
a shopping cart. It wouldn’t be fun if you (the 
shopper) got a cart, put something in, but then 
when you go to put the second thing in, the 
first thing vanishes from the cart. Not too user- 
friendly. So, a good shopping cart will keep the 
client shopper state (i.e. the items in the cart) 
for as long as the shopping session is alive. (We’ll 
explain what we mean by alive in the Session Bean 
chapter.) 


Stateless beans simply forget about the client 
once the method call completes. So, stateless 
beans are for services that don’t require a 
continued conversation between the client and 
the service. That doesn’t mean the client won’t 


keep calling methods on the stateless bean, but 
it does mean that the client can’t depend on the 
bean remembering anything about the previous 
method calls. 


Stateless beans CAN 
have state! (Just not 
client-specific state-) 

Some people think “stateless” means 
“ n0 state”. A stateless bean can have 
instance variables like any other object, 
it just can’t use them to maintain values 
specific to a particular client 



I've heard that only 
stateless session beans are 
scalable, and that nobody should 
ever use stateful session beans. 

Is that true? 

A- 

No, not completely. It is 
true that stateless session beans 
are generally more scalable than 
stateful session beans because 
of the way stateless beans are 
managed by the container. You’ll 
see the reasons for this in the 
Session Bean chapter. 

But... that doesn’t mean you 
should never use stateful beans. 
You should consider stateful beans 
when you need conversational 
state, and when the alternatives 
for saving that state (like using 
the client to store state, or using 
a servlet to store state, or using a 
database to store state between 
each method call from the client) 
are more of a performance hit 
than the less-scalable nature of 
stateful session beans. 
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intro to EJB 


jharpen your pencil 


Know your bean types. 





Look at the problem description on the left, and put 
a check mark for the bean type that would best fit 
the problem. There isn’t one perfect right answer 
for these... you might decide that one bean type will 
work if you approach it one way, but another bean 
will work if you solve the problem in a different way. 

Entity Message-driven Session bean 

(circle stateless, stateful, or both) 


Booking a ticket for a rock concert 


stateful stateless 


A bank account 


stateful stateless 


Searching a product database 


stateful stateless 


Dating service match-ups 


stateful stateless 


Receiving submitted expense reports, and _ _ _ stateful stateless 

sending them out for approval 


Online expert diagnosis — you describe a _ _ _ stateful stateless 

symptom and the system helps you deter¬ 
mine the cause 

The books in a library □ □ □ stateful stateless 
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13 























bean bullet points 


^OoenAeo^d at ^ 


Session bean: I'm so tired of doing all the work and getting none 
of the glory. 

Bartender: What do you mean ''none of the glory*"? A rent you the 
only bean that’s been required by the spec since the very beginning? 
Since EJB 1.0? 


Session bean: Fat lot of good THAT does me. All anyone wants 
to talk about now is entity beans. Entity beans, entity beans, entity 
beans. Not that I don’t like them—some of my best friends are 
entity beans, but I wish people would talk about what I do. 

Bartender: Now that you mention it, entity beans are mostly 
what folks talk about here at the bar, what with the big CMP 
improvements in EJB 2.0. 

Session bean: And thafs another thing... what is the Big Deal with 
CMP? It’s just going to a database! Seriously, tell me WHAT is so 
special about that? u Ooohhh look! It updated a record!" Please. 

Bartender: Yeah, but the programmers around here seem to like 
not having to do all the database code now. And there's something 
about persistent relationships, I just can’t quite remember... 

Session bean: CMR. Container-managed relationships. OK, even 
I have to admit that CMR makes things a lot easier for developers. 
But thafs not what bugs me—I KNOW everybody likes entity beans, 
but what about ME? What about everything I do? Entity beans 
represent things ir\ the system, but without me, those things don’t 
do much. Maybe an entity has some getters and setters and some 
queries, sure, but not a lot of business logic. To use entity beans in an 
app, you pretty much HAVE to use session beans to do the business 
processing. Like, an entity bean might represent the drinks you sell 
here, and the individual customers, but what good are drinks and 
customers without a bartender? You need someone to actually put 
the entities (the drinks and the customers) together in a meaningful 
way! And that's what session beans do. We do the deals. We work 
with the client to get something done, while entities just sit there 
waiting for session beans to use them. Hey, can I get another one of 
those? And don’t even get me started on message-driven beans... 


[To be continued.] 


— BULLET POINTS _ 

■ EJB is a component-based 
development model. 

■ Components are reusable chunks 
of functionality you can modify for 
different applications without touching 
the java source code. 

■ One benefit of EJB is WODA—Write- 
Once-Deploy-Anywhere. You can 
deploy your EJB 2.0 components 

to any app server that’s EJB 2.0- 
compliant. 

■ WODA means you have to learn 
only one, standard API rather than 
proprietary vendor-specific APIs. 

■ The EJB architecture uses an 
EJBObject to intercept client calls to a 
bean. This gives the server/container 
a chance to step in and add services. 

■ EJB services include transactions, 
security, resource management, 
networking, and persistence. 

■ Beans come in three flavors: Entity, 
Session, and Message-driven. 

■ Entity beans represent a uniquely 
identifiable thing in a persistent 
store; usually that means a row in a 
database table. 

■ Message-driven beans are JMS 
messaging service consumers. 

■ Session beans are... everything else. 

■ Session beans can be stateful or 
stateless. 

■ Stateful beans can remember 
“conversational state” with a client, 
while stateless beans cannot. 
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intro to EJB 


Example: 

The Advice fruy bean 

Before we get into the guts of EJB, let’s 
look at how to develop, deploy, and test 
a bean from start to finish. If you’re 
not already familiar with EJB, you won’t 
understand everything here. Don’t worry 
about it now; we’ll figure it all out in later 
chapters. This is just to give you a feeling 
for what it’s like to get a bean up and 
running. 



Tell your boss 
the report will 
have to wait. There's 
powder at Aspen! 


Our first bean is for the Advice Guy 
service — a remote service that gives back 
an advice String each time the client 
makes a request. We’ll spend the next 


The Advice Gu, 

Our first bean is for the Advice Guy 
service. Each time the client makes 


several pages looking at the process, and 
then we’ll actually make this bean, as a 
tutorial. 


a request, the Advice Guy service 
(an enterprise javabean) gives back 
a piece of stunningly helpful (and 
preternaturally appropriate) advice. 


*ln Head First Java, we deployed the Advice 
Guy service using straight TCP sockets. Now, 
for only five times the amount of code and 
effort, we get to have the same service in EJB. 
Of course, if one felt like it, one could argue 
that the Advice Guy doesn’t really need all 
those EJB services, but we disagree. We’re 
already planning the IPO for this baby. 
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five steps to building a bean 


Five things you do to build a bean: 


package 


A 


import 



^ Code the bean class with all of the 
business methods. 


AdviceBean.java 


package 

h 

i 

package 
headfirst; ^ — 


inport 

javax.ejb.*; 


in^>ort java. 

L 

ception ; 


❺ Code two interfaces for the bean: 
home and component. 


AdviceHome.java 

Advice.java 

<?xml veaTN 
sion= 〃 l.(^ 
encoding 
="UTF-8〃？> 

<!DOCTYPE 
ejb-jar 
PUBInc. / 


ejb-jar.xml 


Q Create an XML deployment descriptor 

that tells the server what your bean is and 
how it should be managed. You must name it 
ejb-jar.xml. 


JAR 

■ 

ejb-jar 


Q Put the bean, the interfaces, and the 

deployment descriptor into an ejb-jar file. 
(There might be more than one bean in the 
ejb-jar, but there will always be just one 
deployment descriptor.) 



,These are the ^ 

steps you II go through 
for almost every bean you II 
make. Coding is simple; the 
\ tricky part is deploying. 




❺ Deploy the bean into the server, using the 
tools provided by the server vendor. 



^ ou don’t need to be an XML expert. 

i v In fact, you don’t have to know anything at all about how XML works. You do need 
to know about many of the deployment descriptor tags, but you don't need to know 
about XML in order to learn the tags. If you think of the tags as simply labels in a document, 
with very specific requirements for what you’re allowed to type within those labels, then all you 
need to know for the exam is the name, and requirements, for some of the most important labels 
(tags). Well look at those crucial tags in several chapters. 
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intro to EJB 


1 bean class 

2 interfaces 

3 XMLDD 

4 ejb-jar 

5 deploy 


package 

headfirst. 

D| 

import 
javax.ejt 
import jc 

■ *; 

va. 

rmi. RemoteEx 

ception ，- 



AdviceBean.java 


o Write the bean class with 
the actual business methods 
the client calls. 


This is where it all happens. The 
implementation of your business 
methods defined in the component 
interface. In other words, you write your 
business logic in the bean class. 

There are three bean types to choose 
from, Session, Entity, and Message-driven, 
and we’ll cover each one in detail in later 
chapters of the book. Before making 
a bean, though, you must decide what 
type you need because your bean class 
must implement one of three interfaces, 
depending on the type you choose. 


We’ve chosen a Session bean here 
because it’s perfect for the Advice Guy 
application. Advice Guy gives back 
an advice String when you invoke the 
surprisingly-named getAdvice() method. 
So our bean class (on the next page) 
implements the SessionBean interface. 
And SessionBean isn’t just a marker 
interface* — it has methods your bean 
class must implement. 

The methods you implement from 
the SessionBean interface are known 
as container-callbacks, because the 
container uses them to notify you of 
important milestones in the bean’s life. 


*A marker interface (also called a tag interface) has 
no methods to implement and exists so that you can 
announce to the world that, “Yes, I can do this.” 


ytit 




public String getAdvice () { 

// advice generating code 


f To write all"^ code 
development tool. 

加卿 ededt0 a k ； Z == s e S 
r，for ^ es ^ g ^ eans you Should 

^ J e S an EJB-aware development 

?ol that builds some ofth : bean : 

。二 T 工二二 few 

know for 加 1 the gory details. 

St n oCr af you WLL need 

all before we’re done. 

Z'oy^ent 
iter.) 
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the bean class 


Bean class 


package V^v 
headfirst; 

import 

javax.ejb.*; 
import java. 
rmi. RemoteEx 
ception; 


AdviceBean.java 


The AdviceBean implements the SessionBean interface, so it must implement 
the methods declared in javax.ejb.SessionBean. We’ll grill you on everything 
a little later, for now, just remember that the bean class is where your actual 
business logic goes. In other words, the reason your bean exists in the first 
place. For the Advice Guy, that means the getAdvice() method. 


package headfirst; 


,^ if i\, t tWrec 

need y oU MUST ^ Mcssay PvWc^ 


importjavax . ejb .*;^ ⑽卿一 •• - - 

public class AdviceBean implements SessionBean { 


private String [ ] adviceStrings = {''One word : inappropriate . ", ''You might 
want to rethink that haircut .”， ''Your boss will respect you if you tell him 
what you REALLY think of him.", ''Visualize yourself with better clothes.", 
、 '0f course you don^ t have to go to work today. 〃, ''Do you really think you 
should be leaving the house like that?", ''Read a book, once a year whether 
you need to or not."}; 


public void ejbActivate() { 

System. out. print In (''e jb activate"); 

} 

public void ejbPassivate() { 

System. out. print In (''e jb passivate") 

} 

public void ejbRemove() { 

System. out .printIn (''ejb remove"); 

} 


public void setSessionContext(SessionContext ctx) 
System. out .printIn (''session context"); 

} 


public String getAdvice () { 

System. out .printIn (''in get advice") 
int random = (int) (Math.random() 
return adviceStrings[random]; 



JW business mc-thod 

⑽忠 tt. 


女 


adviceStrings.length) 




^一 Pi^ally/ The ac-tual 

匕 busihess method -the 

^ompohch-t H's 

仏 e whole poihi o( the 

ihc ihi^ ih c 

wahts ■{» u||. 


public void ejbCreate() { 

System. out .printIn (''in e j 

} 



create ”） 
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intro to EJB 



1 bean 

2 interfaces 

3 XMLDD 

4 ejb-jar 

5 deploy 


package I 
headfirst; 


import 
javax.ejb .* 
import jave 


.RemoteEx 


ception; 


Advice .java 


package 

headfirst. 


import 
javax.ejb 
import ja 

• * ; 

va. 

rmi. RemoteEx 

ception ; 



AdviceHome.java 


Write two interfaces for the bean. 


These are the interfaces the client sees. We have an entire chapter 
devoted to these interfaces, so you don’t have to understand it all now. 


COMPONENT interface 

This is where all the business methods are declared. In other words, 
it’s where you put the methods the client wants to call. 


package 

headfirst; 





javax.ejb.*; 
import java, 
rmi. RemoteEx 
ception; 


Advice .java 


component 

interface: 

business 

methods 


package headfirst; 

import javax.ejb.*; 

import j ava.rmi.RemoteException 






public interface Advice extends EJBObject 


public String getAdvice () throws RemoteException 


L , “ 如 ㈣ 购七 

You 州 ust dc^lavc Rcr^o-bc- 

or\ all r»\C*t^ods m 

; tWis m 七 evW! 


咖 dbss. 


HOME interface 

The client uses the home interface to ask for a reference to the 
component interface. The home is the client’s starting point for getting 
hold of a reference to a bean (or at least what the client thinks is the 


package 

headfirst; 




import 
javax.ejb.*; 
import java, 
rmi.RemoteEx 
ception ，- 


AdviceHome.java 


home 
interface: 
a factory 
for bean 
references 


bean, but we’ll get to that later). For now, think of the home as a kind 
of factory that makes and distributes bean references to clients. 


package headfirst; 


import javax . e jb . *; as 如吡 ’ 

import j ava . rmi . RemoteException; ^ oAaIHowC) n^C s 

♦ or 

丁 W、s t 、 二 W 二 “ 私冰⑽ 

public interface AdviceHome extends EJBHome { P / 

public Advice create () throws CreateException, RemoteException; 





you 浐 


you are here ► 


19 











the bean / interface relationship 


Wait just a minute 
here... how come were 
making the bean class 
before the interfaces? 
That doesn’t sound right. 



Hmmm... two good questions. In a non-bean Java world, the way we’re 
doing things here wouldn’t make much sense. But bean world has 
different rules and practices. We could write the interfaces first, and 
some developers do. Sometimes the choice of which to develop first 
depends on the development tools you’re using to build your beans. 
Some tools, for example, expect you to first build your bean (coding 
the actual business logic), and then the tool will build the interfaces 
to match. And some tools do just the opposite, looking at the 
interfaces and building a “your code goes here” bean class, with all 
of the methods from the interface. For learning EJB, we like to start 
with the bean, focusing on the business logic, before figuring out the 
interfaces. Later in the book, we’ll do it the other way around. 

As for the bean not implementing the component interface, you could 
do it that way, but this time we strongly urge you not to. On the next 
page, we’ll look at this in more detail. 
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intro to EJB 


So why doesn't the bean 
class (AdviceBean) implement 
the component interface (Advice) 
if it has to implement the same 
methods? Java classes are allowed 
to implement more than one 
interface, so what’s the problem with 
saying: 

class AdviceBean implements 
Advice,SessionBean 

A- 

厂 Legally, the bean class can 
implement the component interface, 
but the spec doesn’t recommend it. 
Remember, although to the client it 
looks as though the AdviceBean is the 
object the client’s invoking methods 
on (the object that implements — in 
the true Java sense — the component 
interface), the client really invokes 
methods on something called an 
EJBObject, that’s implemented by the 
server at deploy-time.The client never 
interacts directly with the bean. Never, 
ever, ever. Later in the book, you’ll see 
that if the bean does implement the 
component interface,you could sneak 
things past the compiler that would 
explode at runtime. So we strongly 
urge you not to have your bean 
implement the component interface. 

But there’s another issue as well — the 
component interface extends another 
interface. In our example, Advice 
extends EJBObject, and EJBObject 
is not a marker interface. It has 
methods! This means that any class 
implementing Advice must also 
implement the methods of EJBObject! 

So, your bean would end up 
implementing a bunch of methods it 
should never have (like getHandleO, 
getEJBHomeQ...) 


^LereiSireriP 

Dumb Questions 


But there’s an easy solution to 
THAT problem: you could have the 
bean extend a class that has all the 
implementations that you need to 
satisfy the compiler, but don’t really 
need to implement in your code. Like 
the adapter event listener classes in 
AWT. Why not do something like that 
here and make a superclass for your 
bean that implements the methods? 


Yes, you could do that, and it 
would be legal. But it still means your 
bean is capable of having methods 
invoked that the bean should 
never know about.The methods of 
EJBObject are methods for the client 
to call on the bean, but NOT for the 
bean to actually implement. So it’s not 
the best 00 practice. 

And there’s still another reason why 
it’s not good practice to have the 
bean implement the component 
interface — if the interface is remote 
(and EJBObject is, since it extends the 
java.rmi.Remote interface), that would 
make the bean class a Remote class, 
and that must never be! The bean is 
protected by the server, and must 
never be accessed in any other way, 
by anything but the server. It’s the 
server that makes the EJBObject (by 
implementing the Advice interface), 
which IS remote, and which intercepts 
all business method calls to the bean. 


But if you don't have the 
bean implement the interface, in 
other words, if AdviceBean doesn't 
implement Advice, doesn’t this mean 
that the compiler won’t catch you if 
the bean blows it and doesn’t match 
the methods of the interface? 

A- 

Yes, that's exactly what it 
means. And yes, that makes most 
Java developers a little queasy just 
thinking about it. After all, that’s one 
of the benefits of interfaces in Java — 
that the compiler guarantees that 
you have all of the interface methods 
properly implemented. 

But don’t panic! In our development 
in this book, we do have to be careful 
since the compiler isn’t making sure 
that we’ve implemented the business 
methods from the component 
interface. In the real world, however, 
you'll almost certainly be using an 
EJB-ready development environment 
that will make sure you provide the 
methods, either by putting a "your 
code goes here" version of the method 
in your bean class, or by doing the 
reverse — finding the business method 
in the bean class and putting it into 
the component interface. At the very 
least, most servers will check (before 
or at the time you deploy the bean) 
that your component interface and 
bean class have matching methods. 

If this still bothers you, though, we do 
have a technique for getting around it 
that we’ll look at a little later. Chances 
are, you won’t need to use it. 
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bean Brain Power 


naming 
convention 
for beans is 
NOT part of 
the EJB spec. 

Advice, AdvicGHome, 
AdviceBean... 

You’re not required to use these 
names for enterprise beans! 

(Ifs a really, really, really good 
idea, however.) Be sure that 
you^e not fooled by the name 
of a class or interface—it’s legal 
to have a component interface 

named AdviceHome dnd a 

component interface ndmed 
AdviceBean, for example. On 
the exam, always go by the 
class or interface declaration 
rather than the name of the class. 


You saw how the bean doesn’t implement the component 
interface, even though the bean must have the same methods. 
Brainstorm a way (there may be more than one) in which you 
could handle these requirements for the Advice Guy bean: 

1. The component interface (Advice) must extend EJBObject. 

2. The bean must implement the SessionBean interface. The 
bean must not implement the component interface (Advice). 

3. We want the compiler to verify that the bean (AdviceBean) 
has the same methods as those in the component interface. 

(Hint: “the same methods as those in the component inter¬ 
face", does not mean the same thing as “the same methods 
as those declared in the component interface .”） 

(Hint: this requires only Java knowledge, not EJB knowledge.) 



Bean-aware 

development 

tools 


Today, many EJB programmers use EJB-savvy development 
tools. In other words, a bean-capable IDE that knows how 
the three pieces — home interface, component interface, 
i i and bean class — are related to one another. Many of 

L/tt the pQt/l these tools also know how to talk directly to one or 

more app servers, so that you can use the tool to both 
develop and deploy your bean, rather than switching from 
a development environment to the server’s own (and often 
less-friendly) deployment tools. One of the advantages of an 
EJB development tool is that you might not have to worry about 
matching up the business methods in the component interface 
with the actual bean class, or vice-versa. A good EJB-aware IDE 
will make sure you’ve got everything synced up. 
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intro to EJB 


1 bean 

2 interfaces 

3 XML DD 

4 ejb-jar 

5 deploy 


?xml ven 
ion= w 1.0^ 


encoding 


<!DOCTYPE 
ejb-jar 
PUBInc. / 


ejb-jar.xml 




O Create an XML dGployniGnt descriptor ! s y )G0 \ C) 

that tells the server what your bean is and how ^ 七 Lr % ) 

it should be managed. a^\o^ } c ^ oS 


The deployment descriptor (DD) describes the structure 
of your bean including how the three files (component 
interface, home interface, and bean class) are related to one 
another. The server won’t look at your naming convention 
and figure out which is the home, which is the bean, etc. You 
have to tell the server, through the DD, which class is which, 
and how they’re connected. But the DD does a lot more than 
that. And for some beans, the DD can be several pages long! 

For this simple bean, the DD is short. Remember, you don’t 
need to memorize the syntax of the XML in the DD. Later 
in the book (in several different chapters), we’ll go over the 
aspects of the DD that you do need to know. 

<?xml version= 〃 l.encoding= 〃 UTF-8〃？> 

<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems , 

Inc. / /DTD Enterprise JavaBeans 2.0//EN A 'http:// 
java.sun.com/dtd/ejb-jar_2_0.dtcT > 

<ejb-j ar> 

<display-name>Ejbl</display-name> 
<enterprise-beans> 

<session> 

<display-name>AdviceBean</display-name> 

<ejb-name>AdviceBean</ejb-name> 

<home>headfirst. Advi ceHome< / home> 
<remote>headfirst. Advice</remote 〉 

<ejb-class>headfirst.AdviceBean</ejb-class> 
<session-type>Stateless</session-type> 

<transaction-type>Bean</transaction—type> 
〈 security-identity 〉 

<description></description 〉 

<use-caller-identity></use-caller-identity 〉 
</security-identity 〉 

</session> 

</enterprise-beans> 

</ejb-jar> 


You don’t kave to write 

tke XML kand il you 

use a tool tkat can kelp 
you Luild a deployment 
descriptor* 

You can use tke JZEE 
RI tean wizard to Jo it 

for you, anct tke XML 

it spits out will work in 
any EJB Z*0 container! 
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the ejb-jar 


1 bean 

2 interfaces 
3XMLDD 

4 ejb-jar 

5 deploy 啡扭 

o Put the bean, the interfaces, and the 

deployment descriptor into an ejb-jar file. 



^ d 


ovavscWcs ； 

o vt) 


As a bean developer (officially called a Bean Provider), you’ll always put your beans in 
a JAR. The spec says an ejb-jar is a JAR file that holds the things the bean depends on 
(classes and interfaces, along with the deployment descriptor). 

You don’t have to do this by hand since we’ll use the RI! Rather than writing the XML DD 
and using the jar tool to package it, we’ll use the RI deploy tool wizard to make it 
easier (and less error-prone). In other words, we’re going to combine steps 4 and 5 into 
one. For now, you need to know that a bean isn’t a bean until you make a JAR file with 
the compiled class and interfaces, and the DD. 









\ 





Watch it! 




vei T^ 

1 . 0 ^ 


sion: 
encoding 
= 〃 UTF-8"?> 

<!DOCTYPE 
ejb-jar 
PUBInc. / 


ejb-jar.xml 


101101 
10 110 1 
0 11 0 
001 10 
001 01 


101101 A 
10 110 1 
0 11 0 
001 10 
001 01 



Advice.class 


101101 A 

10 no 1 
0 11 o 
001 10 
001 01 




AdviceBean.class 


AdviceHome.class 


The exam expects you to know what is supposed to be in the ejb-jar file and also 
what is not supposed to be in there. The classes and interfaces generated by the 
container (you’ll learn what those are a little later) must not be in the ejb-jar file! Think 
of the ejb-jar as the thing you create, as a bean developer. It’s your deliverable' The 
container/server has its own deliverables, and those deliverables don l t go into the ejb- 
jar. Imagine that you work for Beans-R-Us, and you don’t even have an EJB-capable 
server. That’s the whole idea of the ejb-jar: it’s where the bean developer puts his 
building block components (i.e. beans), that some other developer can use to assemble 
an application. You might use a server tool to help create the XML DD, but the DD is still 
yoar deliverable, regardless of who (or what) creates it. 
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intro to EJB 


1 bean 

2 interfaces 

3 XML DD 

4 ejb-jar 

5 deploy 

o Deploy the bean into the server, using the 
tools provided by the server vendor. 

Sooner or later, your beans have to do something. They have to be assembled 
into an application and deployed into a server, waiting for clients to call. 

This is a huge step. In fact, we cheated a little, because it’s actually two steps: 
Application Assembly and Deployment. 

+ Application Assembly 

This means taking the bean from the reusable component stage to being part of 
an application. For simple beans, that might mean simply writing a client that 
can access the bean (i.e. call the bean’s business methods). In other words, a 
single bean might be the entire application on the server side. But this could 
also be the step where you integrate multiple beans (and other Java classes) 
into a custom application, and that usually means taking different beans (each 
in its own ejb-jar with its own DD) and putting them into a new, single ejb-jar, 
with a single DD that might describe how two or more beans are related to one 
another. 

During assembly, you might also add new information to the DD, for things the 
bean developer didn’t know about. For example, the bean developer might 
write code that uses a special bean-specific “property” (called an environment 
entry, which we’ll get into in a later chapter) for the tax amount used by this 
application. But the bean developer has no idea what value to give the tax 
amount property, so he leaves the value blank in the DD. Then the application 
assembler comes along, sees (by reading the DD) that the bean uses a property, 
figures out what the value should be, and adds it to the DD. 

For the Advice bean, putting the bean in the ejb-jar, building the DD, and 
deploying will happen as one big step. 

+ Deployment 

This is where the rubber meets the road, the bean meets the server, the 
developer meets the sys admin. The two crucial parts of deployment are naming 
the bean (so the client will know how to find it) and getting the bean into the 
container’s control. 

The spec doesn’t say anything about the way in which you deploy your beans; it 
all depends on the EJB server/container that you’re using. 
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EJB roles 


W Roles and Responsibilities 


I work for Beans- 
R-Us, and I develop 
reusable components 
that we sell to other 
developers. 


EJB Role: Bean Provider 


Bill 





Deliverable: ejb-jar files (that 
include one or more beans and an XML 
deployment descriptor) 

Primary responsibility: Design and 
program enterprise java beans. In other 
words, write the bean code. 

Characteristics: Knows the business 
logic that should be in a particular type of 
component, for a particular domain. 


I*m a developer for a 
big online bookstore. 

We buy a lot of beans from 
Beans-R-Us, but I also make my 
own beans. I mix them together 
into new applications customized 
for the business rules of how 
we sell books. 


\Y\Y\\C 


The exam 

j , covers subtle 

: ch it! differences 

between roles- 

Pay very close attention to any 
mention of EJB roles in this 
book, especially when we cover 
more details of the deployment 
descriptor. Count on being tested 
on who does what, and count 
on those questions being subtle. 
The App Assembler and Bean 
Provider overlap in several areas, 
as does the Deployer and the 
App Assembler. For the exam, 
you need to know which role has 
the primary responsibility for a 
particular task (usually having to 
do with the deployment descriptor 
information). The stuff on this page 
and the next are just a start... 


EJB Role: 

Application Assembler 


Deliverable: ejb-jar files (that include 
one or more beans and an XML 
deployment descriptor with Bean 
Provider info as well as application 
assemib/y info). May also create clients 
or define interaction between other 
components (such as JSPs). 

Primary responsibility: Combine 
one or more enterprise beans into a 
larger application. May sometimes wear the Bean 

c 

Provider hat, mixing new and existing beans 
together to build an app.Defines the security and 
transaction behavior for the application. 

Characteristics: Definitely a domain expert. 

Might not do as much coding as the Bean Provider. 
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intro to EJB 


EJB Role: Deployer 



end up on Dick’s server. Bill had to make up a l fake J name 
for the database, and Dick has to bind the fake name to 


something real. 


Characteristics: An expert in a specific operational 
domain. Knows the security users and roles for this 
system, knows what’s configured into the server, and 
understands how to interpret the deployment descriptor 
info from the Bean Provider and App Assembler. 


Wow! It actually deployed. 

Unbelievable. I work for 
the same online bookstore as the app 
assembler, and I take her ejb-jar, study 
the deployment descriptor, and get the thing 
actually running into the server and waiting 
for clients. I know a LOT about the way our 
systems are configured and running here. 


Deliverable: Enterprise beans that have been 
customized for a specific operational environment, and 
deployed into the server. 

Primary responsibility: Take the Application 
Assembler’s deliverable, study the deployment descriptor, 

and resolve any external dependencies. For example, 
if the bean relies on a particular resource, the deployer 
must map the logical name from the Bean Provider to the 
actual name of the resource on the server. Remember, 
when Bill wrote the bean code he didn’t know it would 


EJB Role: 


Deliverable: EJB 2.0-compliant server, deployment 
tools, runtime environment for enterprise beans. 


Primary responsibility: Implementing the spec. 


Characteristics: Experts in distributed objects and 
transactions, and other low-level system services. 


We work for the 
SuperServer company. 
Were experts in low-level 
services like transaction 
management, pooling, and 
security. 


Container and Server Provider 


We do the 

big services so you get 
to focus on your business logic. 
We compete with IBM, BEA, 
and Oracle, and someday well 
kick Larry Ellison’s butt. 
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AdviceBean tutorial 


Tutorial: 


Let’s make, deploy，and test the AdviceBean 

We’ll write the code, compile it, start the server, start the 
deploytool, use the deploytool to make the DD and the 
ejb-jar, deploy the bean, create a client, and test the bean 
using the client. The only thing we won’t do is install and 
configure the server. We assume you already did that. 

If you don’t yet have the J2EE 1.3 RI up and running, go 
to http://java.sun.com/j2ee/ and download version 1.3 
ofJ2EE (it includes set-up instructions), then go back and 
download the J2EE API documentation. 


Why are we using 
the RI? Why can't we use 
a REAL app server? 


£hc exam is JZEE 

心广 j d T do 

WT siudy u the exar, usi h g 
S P C ^* -the ih-t\ro (oy move 

d j ihc 

如 d 4 /. 午一忪“七 ve^sio, is ： 

somctUg-that sUost hobody is usi h a. 
CMcshoy. is HOT abou-t 1 k,ow 9 

^bout I k,ow ihc tedUology iU 

^ ^ six r ， o,-ths. w 3 



o 


Which server would we use? We use the 
RI for learning and practicing because 
we don’t know which server you’ll need 
to use, and the RI is the simplest of all 
the freely-available servers. We want 
it to be as easy as possible for you to 
focus on EJB technology and ignore the 
tool-specific tasks. 

Open source products like JBoss are 
still real production servers, so they tend 
to have a lot more configuration and 
administration tasks to cope with. Using 
the RI lets you spend more time doing 
the things you’ll have to do, regardless 
of the server, with the least amount of 
time spent learning a server-specific 
approach to those things. 



Therms nothing 
on the ® xar ^ EE R |. 

about the J2£ : 

― Oranyot^^ 

•. every need to know 

'• have, bu ^° 5 pe cific features or 

' S : 工一. .......... 

•• . 
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intro to EJB 


Organize your project directory 

All the beans in this book are organized into packages, which means you 
must be a little more careful about compiling and running. Every instruction 
in this chapter assumes you’ve organized your project exactly the way it’s 
shown here. If you deviate from this structure, you’re on your own for 
mapping our command-line and deployment formulas to your own structure. 


c 

o 

■ ■■ 

n 

N 

C 

扣 

Uf 

o 

芯 

o 

百 

Q. 


)roject in the book has its 
rectory. This directory is 
advice project. 


Each project has a 
sre directory (for .java 
source files) and a 
classes directory (for 
.class bytecode files). 


This is where the package 
directory structure begins. 
Most project classes are 
in the “headfirst” package, 
which means the classes 
must be in a directory 
named headfirst. 


headfirst 


.class files 
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There’s only ONE projects 
directory for the whole 
book. 



di 


package I 
headfirst; 


javax.ejb.*; 
import java. 
rmi.RemoteEx 
ception; 


.java files 


101101 
101101 
10101000010 
1010 10 0 
01010 1 
1010101 
10101010 
1001010101 

.class files 


package 


in^>ort 
iavax. ei] 

5 .*； 

in^jort j 

ava. 

rmi. RemoteEx 

ception ，- 



java files 


Organizing your terminal/ command-line 


compile from the sre directory 


run clients from the specific 
project directory 



101101 VN 
101101 
10101000010 
1010 10 o 
01010 1 
1010101 
10101010 
1001010101 



〜 /projects/advice/src 
〜 /projects/advice 


a) c)e>loea 












































compiling the interfaces and bean class 


Compile the two interfaces 
and the bean class 


So far, we’ve written the two interfaces and the 
bean class, but we still have to compile them. 
After that, we’ll make the ejb-jar (which holds 
class files, not source files). 


File Edit Window Help WhyAmIHere 


%cd 〜 /projects/advice/src 
% javac -d . . /classes headfirst/* • java 


We’re using the -d compiler flag, so the command¬ 
line above says, “Compile all the .java files in the 
‘headfirst’ directory, and then put the compiled 
.class files into the ‘classes’ directory, which you’ll 
find by going up one level from the current (sre) 
directory. Oh yeah, almost forgot, be sure to put 
the classes in their correct PACKAGE directory. 
Look for the package structure inside the ‘classes’ 
directory, which means you should see a directory 
named ‘headfirst’，and THAT’S where the class 
files need to go...and if you do NOT find the 
‘headfirst’ directory there, then make one for me. 
Thanks.” 


Right now, this is how 
your projects directory 
structure should look: 



1 "^— 1 - ^ 


1 - - 

headfirst 


headfirst 





y/ C a . 

Ue 4 



AdviceBean.java 


Advice.java 


AdviceHome.java 
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intro to EJB 


Start the server 

Open up a new terminal for the server. You’ll leave it running, and we 
want to see the output, as it runs, so don’t use this terminal for anything 
else. Make the advice directory your working directory. 



You'll see something like this 

The -verbose flag (which isn’t required, but we like 
it) prints out a bunch of stuff in the terminal. 


I File Edit Window Help WhatThe...? 


% j2ee -verbose 

J2EE server listen port: 1050 
Naming service started:1050 

Binding DataSource, name = jdbc/DBl, url = jdbc : cloudscape : rmi : CloudscapeDB;create=true 
Binding DataSource, name = jdbc/InventoryDB, url = jdbc : cloudscape : rmi : 

CloudscapeDB;create=true 

Binding DataSource, name = jdbc/DB2, url = jdbc : cloudscape : rmi : CloudscapeDB;create=true 
Binding DataSource, name = jdbc/EstoreDB, url = jdbc : cloudscape : rmi : 

CloudscapeDB;create=true 

Binding DataSource, name = jdbc/Cloudscape, url = jdbc : cloudscape : rmi : 

CloudscapeDB;create=true 

Binding DataSource, name = jdbc/XACloudscape, url = jdbc/XACloudscape_xa 

Binding DataSource, name = jdbc/XACloudscape_xa, dataSource = COM.cloudscape.core.RemoteX 

aDataSource@ 4 c6715 

Starting JMS service... Initialization complete - waiting for client requestsBinding : < 

JMS Destination : jms/Topic , javax.jms.Topic >Binding : < JMS Destination : jms/Queue , 
j avax.jms.Queue >Binding : < JMS Cnx Factory : QueueConnectionFactory , Queue , No prop¬ 
erties >Binding : < JMS Cnx Factory : jms/TopicConnectionFactory , Topic , No properties 
>Binding : < JMS Cnx Factory : jms/QueueConnectionFactory , Queue , No properties >Binding : 
< JMS Cnx Factory : TopicConnectionFactory , Topic , No properties > 

Starting web service at port: 8000 
Starting secure web service at port: 7000 
J2EE SDK/1.3.1 

Starting web service at port: 9191 
J2EE SDK/1.3.1 

J2EE server startup complete. 
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starting deploytool 


Start deploytool 

Open up a new terminal for the deploytool. This tool is 
part of the J2EE RI, and it has everything you need to 
create the ejbjar, the DD, and to do the final deployment 
into the RI server. 


I File Edit Window Help Chill 


%deploytool 

Starting Deployment tool, version 1.3.1 

(Type 'deploytool -help' for command line 
options.) 


you’ll see something like this 


A lovely splash screen pops up and sits while the 
application loads. If you click the splash screen, it 
disappears, so don’t panic if it then looks like nothing’s 
happening. Patience. 
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intro to EJB 


Make a wcw Application 

The RI is aJ2EE server, remember, not just an EJB container. 
So we have to do a small bit of J2EEish stuff before we can 
make the ejb-jar and deploy the app. This step is where 
we create a newJ2EE application, and for now, you can 
think of the J2EE application as something that wraps the 
beans and adds a little more information for the server. 
The main difference between aJ2EE application and an 
EJB application is that aJ2EE application can include web 
components (servlets andJSPs) as well as EJB components, 
all integrated as part of a single app. 

Choose File ► New ► Application 



Dumb Questions 




Does this mean that I 


MUST have a J2EE server if I 
want to use servlets and EJBs 


together? 


A- 

No. With a J2EE server, 
the web components and EJB 
components are more tightly 
integrated, which means you 
can have all of the components 
respect one another’s transac¬ 
tions and security. But you’re 
always free to use a servlet as 
a client to an enterprise bean, 
even if that bean isn’t running 
in the same application server 
(or even the same physical 
machine). Another advantage 
of a J2EE server is the ease with 
which you can deploy both 
component types as part of one 
enterprise application. 

Having said all this, chances are 
extremely high that if you’re do¬ 
ing EJB 2.0 applications,you are 
running them in a J2EE server. 
Remember, there are very few 
standalone EJB containers 
today. Virtually all significant 
vendors run their EJB containers 
within a J2EE server. 



A J2EE server vendor must pass a 
massive pile of compatibility tests 
before the server can be called 


“J2EE-compliant”. A J2EE 1.3 server, 
for example, must include an EJB 2.0 
container, and that container must 
implement the EJB 2.0 specification. 
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deploytool: making a new application 


Name and save the wcw application 

This part’s a little awkward. You can use the Browse button to navigate 
through your own directory tree, but the easiest way to name and 
save the application is to type the complete path to the file you’re 
about to create. The thing we’re making is not the bean itself~you 
can think of it more like a document that holds all the information 
about the application. As a convention, we save the application in 
the projects/ [whatever] directory — the directory corresponding to 
that particular project. For the Advice bean, that means the projects/ 
advice directory. If you started the server from the projects/advice 
directory (in other words, if advice is your current working directory), 
then you’ll get the right name and location by default. 

Name the application AdviceApp 

If needed, include the full path to projects/advice/AdviceApp 

Click OK 
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What youll see after you create and name 
the application 

Now, you’re back at the main screen of the deploytool. You might 
have to click on the Files or Applications icons to expand them, but 
you’ll see that the tool has created an Applications directory with 
something called AdviceApp inside. Click on the AdviceApp icon, 
and you’ll see information about the application including the 
name, location, and current contents. At this point, there’s nothing 
but a META-INF directory (that holds more info about the app, 
which we won’t ever need to look at). 


Click on the AdviceApp icon 
































































































deploytool: making a new enterprise bean 


Now let's make the new enterprise 
bean (the ejb-jar awd the PP) 

This is what we’re really after — the actual bean. The previous 
steps (making the J2EE application) were to satisfy the J2EE RI 
because we have to deploy the bean within aJ2EE app. 


Choose File 卜 New 卜 Enterprise Bean... 
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intro to EJB 


Now wcVc iw the really cool 
New Enterprise Peaw Wizard 

This part of the deploytool is where almost everything happens! 
The key things we’ll do are: 

命 Create the ejb-jar 

^ Put the bean class and the two interfaces into the ejb-jar 
+ Create the deployment descriptor that describes the bean 


Click Next > 
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deploytool: create a new ejb-jar 


Create the new ejb-jar 

For now, just accept the defaults. The radio button on the top left of 
the screen shows that you’re making a new JAR within the AdviceApp 
application. Notice that the AdviceApp is part of a drop-down list — if 
there were other ejb-jars already in the application, we could have 
chosen to put the new bean in a pre-existing JAR. 

The tool picks an especially helpful display name, “Ejbl”，and you’ll see 
this back on the main deploytool screen when we’re done. That name 
isn’t used anywhere in your real application, so it’s no big deal, but if 
you have more than one JAR in an application, you might want to give it 
a more descriptive name (Cart JAR, Account JAR, etc). 


Click Edit... 
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intro to EJB 


Add the three class files (including their 
package directory) to the JAR 

This is the most important part of the whole process! In other words, don’t 
screw it up. The key is to get the correct classes into the JAR in their package 
directory structure, and only their package directory structure. In other words, 
if you put the three class files into the JAR without the headfirst directory, 
your bean won’t deploy. Or, if you include the classes directory as well as the 
headfirst directory, your beans won’t deploy. Remember, the ejbjar is still a 
JAR file, so the usual JAR rules about package structures apply here. 

Navigate to the Advice directory 

Expand the classes directory to see the headfirst directory 
Select the headfirst directory 
Click Add 



Wse ihe havija-tioh 

y 财 Advice di^Uy, 

you see y ouv . 

i hc hcsd ^ si 
dorceWy. You do^i have 
^ c ^d ii.. wc did 

,you dould see 
“ais i h -thcvc. 
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deploytool: confirm JAR contents 


Confirm that you added ONLY the 
package directory and the class files 

You gotta get this part right. Look at the bottom window that says “Contents of 
Ejbl” and verify that the only thing in the JAR besides the META-INF directory 
is the headfirst directory (including the contents of the directory). The classic 
mistake we see all the time (not that you’d ever do that) is to add only the class files, 
but not the package directory. Be sure that you have the headfirst directory (and 
not the classes directory) with the three class files. Another common mistake is to 
add the source files instead of the class files. So don’t feel bad if it happens to you. 


Verify that you have the right classes (and package directory) 

If you don’t, select them from the bottom window, click Remove, and start over. 
Click OK when you’re done, then click NEXT 
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intro to EJB 


Make it a Stateless Session bean 

Now, we’re at the place where we give the tool the bean’s ‘structural’ information. What kind of 
bean it is, which class file is the home interface, and so on. Remember, the tool uses this to create 
the deployment descriptor. And the EJB container uses the deployment descriptor to figure out 
how to deploy and manage the bean. 

The Advice bean is simple — client calls a method on the remote object, the remote object returns 
a value, then the remote object forgets the whole thing ever happened. End of story. That scenario 
is just perfect for a stateless session bean solution. If the Advice bean needed to remember the advice 
it gave to the client, and use it in some way in future invocations from that same client, then we’d 
make it stateful. But we don’t，so we won’t. 

And as you’ll learn later, it wouldn’t make sense to have the Advice bean be an entity or message- 
driven bean. But it’s too late to make it anything but a session bean anyway — your bean class 
implements the SessionBean interface. So you’re already committed to a bean type. But whether 
the session bean is stateless or stateful can be a little more subtle. For now, just make it stateless. 

Select the Session radio button 
Select the Stateless radio button 



&‘七 ih c A/cxi 
bu-tU// have way 

-to do o, -this 
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deploytool: relating the bean’s .class files 


Tell it which of the three class files m the JAR 
is the actual gEAN class 

You have three class files in the JAR: the home interface (AdviceHome), the 
component interface (Advice), and the bean (AdviceBean). But the EJB 
container needs to know which is which. Remember, the naming convention 
doesn’t mean anything to anyone but you! The container won’t look at the 
three classes in the JAR and recognize that AdviceHome must be the home 
interface, and so on*. No, the naming convention is for you and anyone else 
using your bean components. 

So, now you have to tell the tool which of the files is the bean class (we’ll do 
the two interfaces on the next page). The tool, then, will put this info into 
the deployment descriptor. 


Click the Enterprise Bean Class drop-down menu 
Select headfirst.AdviceBean 


e 


?< 


New Enterprise Bean Wizard - General 

Please choose the type of enterprise bean that you are creating and select the class files from the JAR file that are to be used for 
the bean. You can choose to provide only local Interfaces, only remote Interfaces, or both. 

Optionally, you can provide a description and icons for the bean. 


Bean Type - 

O Entity 

C Message-Driven 
⑱ Session 

(•) Stateless 
O Stateful 


headfirstAdvtceB«an 


tor 


headfirstAdvke 

headfirsLActviceBean 

headfirsLAdviceHofne 




▼ 


AdviceBean 


D Description … 


Help... 


Cancel 

< Back 

Next > 




叮 here are some vendor tools 
that can use your naming 
convention, among other 
things, to figure out which is 
the home, which is the bean, 
etc. But the Rl doesn’t do this, 
and development tool support 
is not part of the EJB spec. 
The only tools required by 
the spec are for the Deployer, 
not the Bean Provider or App 
Assembler. 
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intro to EJB 


Tell it which is the Home interface, and which 
is the Component interface 

Now, you have to do the same thing you did for the bean class, but with the two 
interfaces. You’ll notice that there are two different places where you can select 
interfaces — Local and Remote. This bean is remote (which means it’s a Java RMI 
remote service, but we’ll get into that in the next chapter), so we’re using only the 
bottom section, for Remote interfaces. Just leave the Local interfaces section alone. 

The strange part is that this screen uses the term Remote Interface rather than 
Remote Component Interface. That’s just a bad interface design in the deploytool. 
(It’s actually an artifact of the previous version of EJB, when there were only remote 
interfaces. Local interfaces are new to EJB 2.0), but we have to live with it. 

Click the Remote Home Interface drop-down menu 
Select headfirst.AdviceHome 

Click the Remote Interface drop-down menu 
Select headfirst.Advice 
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deploytool: verify structural information 


Verify everything ow this screen! 

Choosing the bean class, the home interface, and the component interface is a 
permanent decision! Once you’re done with the rest of the bean wizard, and the 
deployment descriptor is created, you’re stuck with it. If you accidentally mix up 
the home and component interfaces, your bean won’t work. In the RI, it won’t even 
deploy (some servers let you deploy structurally bad beans, which means they blow up 
at runtime, but the RI won’t even let you in the server door). 


Be sure you have the following settings: 

Enterprise Bean Class: headfirst.AdviceBean 
Remote Home Interface: headfirst.AdviceHome 
Remote Interface: headfirst.Advice 

Click NEXT 



B V,T C you，r 办咖 looks 

J U f lik « ihis bc4^ c you 
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intro to EJB 


YouVc done, click Finish 

Because this bean is so simple, and we don’t care about transactions, security, 
environment entries, and database access, we’ve done everything we need to 
make the deployment descriptor and put it in a JAR with the class files. 

So, you can ignore the Transactions Management screen, although you’ll 
become intimate with it later in the book. 

Click Finish 


e 


New Enterprise Bean Wizard - Transaction Management 

Please choose whether th« bean's transactions are managed by the bean or by the container. 

If they are managed by the container, you can also define what level of transaction support is required for each method In each 
interface. 

Optionally, you can provide a description for each method. 
rTrsnsAdion M^inAQ^rncnt 

㉘ Bean-Managed 
O Container-Managed 


Method 


Transaction Attribute 


¥ 




Help... 


Cancel 


< Back 


Next > 


Finish 


II 
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deploytool: main screen after making a bean 


Meanwhile back on the main deploytool scrccw... 

Things have changed! The AdviceApp icon expands to show your ejb-jar 
(named “Ejbl”），and the ejb-jar expands to show the cute bean icon named 
“AdviceBean”. If you select the AdviceBean, you’ll see a bunch of tabbed panels 
that’ll show you the choices you made in the bean wizard. Some of the things you 
chose can be changed, but some can’t. In the General panel, for example, you 
can’t change the class file designations for the home, component, and bean. In 
fact, you can see that the drop-down lists for these are grayed-out here. But gee, 
you can still change it from Stateless to Stateful. 


Admire your work 
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Ruw your bean through the deploytool verifier 

You already know your bean classes compile, but just because it compiles 
doesn’t mean it follows bean law. The verifier takes your jar and runs it 
through a bunch of tests to see if it meets the minimum requirements for 
deployment. As you learn more about the EJB spec, you’ll see that the 
verifier is testing your bean’s code (and the deployment descriptor) to see 
if it complies with the spec. For example, a stateless session bean’s home 
interface must have a no-arg create () method declared, and nothing else. 
And the bean class must have methods that match those declared in the 
component interface. And if the component interface is remote, it must 
declare that each method throws RemoteException. Don’t worry about 
remembering these examples; it’s just to give you an idea of the kinds of 
things the verifier does. 

Click on the Ejbl icon (the little jar) to highlight it 
Choose Tools 卜 Verifier... 

Cross your fingers 


re o o 


Application Deployment Tool: AdviceApp 


File Edit 


a 



Files 

<? 

9 < 


<p 喔 Serv« 

m 


Tools Help 


Update Files 
Deploy... 

Update and Redeploy... 



6 國 



^ % 

Ikations^AdviceApp.Ejb 1 AdviceBean 

e Env. Refs 

Resource Refs 

Security Transactions 

>eneral 

Env. Entries EJB Refs 


Verifier... 


Clone Inspector 




Edit Roles... 


Descriptor Viewer- 


Server Configuration … 


sion 


Stateless 


O Stateful 


Enterprise Bean Class：_ 

headfirsLAdviceBean 

Enterprise Bean Name: 


AdviceBean 


Enterprise Bean Display Name: 
AdviceBean 


D Description … 


Icons … 


Local Interfaces— 
Local Home Interface: 

Local Internee: 


Remote Inteifaces 
Remote Home Interface: 
headfirsLAdviceHome 
Re mole Interface: 
rsLAdvice 


Remote I 

headfin 










































































deploytool: running the verifier 


Close your eyes and click OK 

The verifier screen shows you the name of the JAR as ejb-jar-ic.jar, in a tmp 
directory, but that’s just how the RI saves your ejbjar until you’re ready to 
deploy. The tmp file (and the JAR) will go away when you deploy or delete 
the bean from your application. 

(At least it’s supposed to. Sometimes you might have to find that directory and 
delete it yourself. Repeat after me: The deploytool is free. The deploytool is 
not a production tool. I did not pay any money for this tool. I will learn to 
appreciate its strengths and look past the 101 ways it is a pain in the a**.) 

Choose the Failures Only radio button 
Click OK 


File Edit Tools 

e o o 




Application Deployment Tool: AdviceApp 

Verify Specification Compliance 


<? a 

9 1 


<? 


-Items to be Verified- 



OK 


Add … 


Delete 


Display ： 

O All Results 

d) Failures Only 
O Failures and Warnings Only 


Oose 


Help 


-Results: (Qick on Item to show test Details below)- 


Item 


Test Name 


Result 
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intro to EJB 


Whew! No failed tests. 


If everything verifies, you see a nice little message in the Details box at the bottom of the 
verifier window. If there are failures, you’ll see them in the Results box. You can click on a 
4 failure 5 message to get more details about what went wrong. Don’t panic if you see a million 
failures; usually you can fix one thing and they all go away. Unlike compiler error messages, 
which are sometimes about as helpful as VCR instructions, the verifier failure messages are 
pretty explicit. You can usually figure out exactly where you went wrong. 

Sometimes, you can fix the problem back in the main deploytool window by clicking on one of 
the tabbed panels and changing something. For example, if you forgot to specify a transaction 
attribute for an entity bean method, you can go to the Transactions tabbed panel in the 
deploytool window and set the attribute, without starting over in the bean wizard. 

But if you have problems with your actual class files, you’ll have to modify them, recompile 
them, and then update your ejbjar*. Or, if the problem is that you made a setting in the bean 
wizard that can’t be changed (like, selecting the bean class when the tool asks for the home 
interface), you’ll have to delete the ejb-jar and start over with the bean wizard. 


Be happy about the wonderful message at the bottom 
Click Close 



「 Results: (Click on Ittm to show test Details below> 



Cli 匕 k Close -fco pu-f ： 
^way -the wihdow. 

you didk OK 

you || jus-t \ruh -the 

饮 agaih. 


*To update your 
ejb-jar file choose 
the ‘Tools’ then 
‘Update Files 5 
menu options. 
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deploytool: doing the deploy 


Time to Peploy 

Once you’ve verified, you’re ready to deploy. There’s not much that can go 
wrong unless something bad happens in the server. At this point, almost 
anything that goes wrong can be fixed by shutting down the server and 
deploytool and starting them back up again. Drastic, yes, but it usually works. 
Sometimes you do have to take even harsher action, by returning the server 
back to it’s freshly installed state, but fortunately there’s a command that 
can do that. When all else fails, bring up a new terminal and type cleanup. 
This script shuts down the J2EE server, but it also cleans out all the logs, 
directories, and files that have been made on that machine. After that, you 
can try starting the server, then the deploytool, and deploying again. And if 
you ever open the deploytool and you don’t see your application, don’t panic! 
Just go to the File menu and choose Open, just like you would to open a 
document in any other application. Think of the J2EE app like a document as 
far as the deploytool is concerned. 

Choose Tools ► Deploy... 
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intro to EJB 


Make it Return a Client Jar 

Once it starts, the server is going to do a ton of things to get your bean ready. One of 
them is to generate the class files that implement your two interfaces (the home and the 
component interfaces). And since they’re remote interfaces, the server will also create 
the remote stub classes for those interfaces. (Lots more on these later.) Well, the client 
needs the two interfaces and the two stubs. You could have given the client the interfaces, 
since you created those. But only the server can make the stub classes, and the client will 
never work without them. So your client application might be sitting there, all nice and 
compiled, and just waiting for you to give it the stub classes so that it can actually run. 

Fortunately, you can ask the RI deploytool to give you a client jar that has everything the 
client needs (and a lot more, it turns out, but since this isn’t a real production environment, 
we’re just going to let that go). 

Virtually all EJB application servers must create the stub classes, so you’ll have to find out 
where your server puts them, so you can give them to the client. 

Select the Return Client Jar checkbox (put it in the projects/advice directory) 

Click Next > 
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deploytool: giving the bean a JNDI name 


ftivc it a name, so clients can look it up 

We’re now dangerously close to deployment, and the last step is to give the bean a 
JNDI name. That’s the name clients use to get a reference to the bean. (Well, to what 
the client thinks is the bean, but we’ll save the gory details for the next chapter.) 

The bean’s JNDI name is simply the logical name you choose (or, in the real world, 
whoever deploys the bean). It doesn’t have to match anything from the bean itself. We 
could, for example, name this bean Homer, which would in fact make it even more 
fun and challenging for the clients than it already would be with a meaningful name. 

Type in the JNDI name Advisor 
Click Finish 

Take a deep breath and hold it until the deploy process completes 
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intro to EJB 


Watch the progress bars go up, thew celebrate 

Wait for it... wait for it... wait for it... 

When the bean’s deployed, successfully, you’ll see the line “Deployment of AdviceApp 
is complete” in the window. At that point, clients can access the bean. 

You did it! 


Click OK 
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deploytool: main screen after deploying 


Now youll see the AdviceApp inside the server 

Under the Servers icon, you’ll see the localhost icon representing the J2EE server 
you started before you launched the deploy tool. And under the localhost icon, you 
can now see that your AdviceApp is deployed. You’ll also see the Undeploy button 
that you can use to, well, undeploy. 

Expand the Servers > localhost icons to see the AdviceApp 
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intro to EJB 


Now all we need is a cliewt... 

We have a freshly deployed bean (in aJ2EE server), but we can’t 
test it until we have a client. The client has to do five things: 


① 


Get a reference to a JNDI InitialContext 

(we’ll learn about that in the Client View chapter). 


② 


Use the InitialContext to do a lookup on the 
home interface of the bean (that we named 
“Advisor” when we deployed). 


③ 


Narrow and cast the thing we get back 
from the lookup. (That thing is something 
that implements the AdviceHome interface.) 
We’ll learn about narrowing in the Client View 
chapter. 


④ 


Call create on the home interface to get 
back a reference to the component interface. 


⑤ 


Call getAdvice() (the business method, 
the reason we’re here, remember?) on the 
component interface, and print the result. 


We 5 re using a stand-alone Java 
program as the client. 

In the real world, your clients 
will likely be servlets or other 
beans. 

The five things the client must 
do are the same regardless of 
the type of client. 

So, using a stand-alone Java 
program teaches you to do the 
same things you’ll need to do 
with a servlet client. 

If your client is another 
enterprise bean, the code will 
be slightly different, but you 
still have to do the five steps. 



There’s nothing on the exam about servlets or JSPs. 

The exam expects you to know how the client gets and uses a 
bean (the steps above), but the type of client doesn’t matter. The client 
code for getting a reference to a bean, and ultimately calling methods on the 
bean, is virtually the same whether the client is a servlet or stand-alone Java 
app. And all the exam cares about is the part of the code where the client is 
trying to get and use a bean. 

The only knowledge of servlets and JSPs you need for the exam, is to know 
that the EJB spec does NOT guarantee support for them. Servlets and JSPs 
are guaranteed by the J2EE spec, but not by the EJB spec. 
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organizing the complete project 


Organizing your project directory for the client 


This is what your projects/advice 
directory should look like after we 
write and compile the client code. 


丁 Ws 


V 


]~ his is 




sc\rvc\r 0ave us 


wheh v/e deployed. 


AdviceApp 


AdviceClient.class 


AdviceBean.class 



i 齡以 


101101 


10 110 1 


101101 

0 11 0 

1 

10 110 1 

001 10 

/ 

0 11 0 

001 01 

/ 

001 10 



001 01 


package | 、 
headfirst; 



package 


f 

headfirst; 

import 

/ 


javax.ejb.*; 

/ 

import 

import java. 


javax.ejb.★; 

rmi. RemoteEx 

/ 

in^jort j ava. 

ception; 

/ 

rmi.RemoteEx 



ception; 


AdviceBean.java 


101101 ^ 
10 110 1 

0 11 0 



package 

headfirst; 

001 10 

001 01 


import 
javax.ejb.*; 
import java. 





ception; 

1 


Advice.java 


AdviceHome.class 


AdviceHome.java 
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intro to EJB 


The Client Code (AdviceClient.java) 


import javax.naming.* 
import java.rmi.*; 
import javax.rmi.*; 
import headfirst.*; 
import javax.ejb.*; 




public class AdviceClient 


public static void main(String[] args) 
new AdviceClient() .go (); 

} 


/ m-to JNPI e ’ 

public void go () { f ^ cv - c >wc do *tV>C lookup. 

try { V. 丨 , L V>car, JKPI 

Context ic = new 工 nitialContext () ; L-ooku^ *tnC f\c* . 

Object o = ic • lookup (''Advisor") ; ( ^ ^drv\C vjC V 

AdviceHome home = (AdviceHome) PortableRemoteObject.narrow(o, AdviceHome.class); 


Advice advisor = home.create(); 

System. out. println (advisor . getAdvice ()); 
catch (Exception ex) { 乂 




ex.printStackTrace(); 




㈣ SS; 


Compile the client: 


| File Edit Window Help AIIThisForJustThat 



%cd 〜 /projects/advice 

TV^c v)AR 

几 e diehi class 

I 

% javac -classpath {$CLASSPATH} : AdviceAppClient.jar 

AdviceClient.java 


The client needs access to the two interfaces (Advice, AdviceHome) and the two stub 
classes that implement those interfaces. They’re both in the client JAR the server made, 
but we can’t compile the client without them. The cleanest way is to add them to the 
classpath at compile-time, using the -classpath compiler flag. 
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running the client 


Run the client! 


File Edit Window Help AIIThisForJustThat 


%cd 〜 /projects/advice 

% java -cp {$CLASSPATH} : AdviceAppClient.jar AdviceClient 


At runtime, the client still needs access to the two interfaces (Advice, 
AdviceHome) and the two stub classes that implement those interfaces. 
They’re both in the client JAR the server made, we have to add them to the 
classpath. The best way is to use the -cp compiler flag. 

Note: For now, the client must be on the same physical machine as the server. 
Later, we’ll see how to change this, and run the client against aJ2EE server on 
a different machine. 


You re kidding me, 
right? All this work just to 
call one little method that returns 
a String? I have to do all this, 
just to do HelloWorld in EJB? 



I think I can answer that—yeah 7 this 
is major overkill for a HelloWorldish 
app like the AdviceBean. But in the context of 
a real enterprise app, with a zillion customers a day 
hitting your server (and an insanely short deadline), 
this extra work, and runtime overhead, is pretty trivial. 
Especially when you consider everything you GET. So, I 
think you need to look at this from a more real- 
world perspective. 

(OK, yes, if youre gonna be all picky about it, 
I'm not real... but that shouldn't 
affect my credibility.) 
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c 办尹 尹它它 


Sxam 


Which are features every EJB 2.0 container must implement or support? 
(Choose all that apply.) 

Q A. A GUI bean deployment utility. 

Q B. Synchronous invocation for all bean types. 

口 C. Transaction support for all bean types. 

口 D. Remote client views for all bean types. 

口 E. JNDI 1.2 namespace. 


之 Which are guaranteed capabilities of EJB 2.0? (Choose all that apply.) 
口 A. Local home interfaces for message-driven beans. 

Q B. Dirty detection mechanisms to reduce memory footprints. 

口 C. Run-as security identity functionality. 

口 D. The JDBC 2.0 extension. 

口 E. Session bean failover. 


Which are features in EJB 2.0? (Choose all that apply.) 
口 A. Portable finder query syntax. 

Q B. Container managed persistence. 

口 C. Local interfaces for session beans. 

Q D. XML based deployment descriptors. 

口 E. Synchronous message-driven beans. 
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mock exam answers 





"TJtoc^ Sxom /ia^uoi^ 


Which are features every EJB 2.0 container must implement or support? 
(Choose all that apply.) . 

•七 dc^U^to U 糾 


(s_: 乂 ) 


口 A. A GUI bean deployment utility. 

口 B. Synchronous invocation for all bean types. - MPBs da^o-t be syy\dh\roir>ous 
^ C. Transaction support for all bean types. 


Q D. Remote client views for all bean types. - A/lT)U 」 
^ . TxmT19 —— 〜 


E. JNDI 1.2 namespace. 


v icy/s 


z 


Which are guaranteed capabilities of EJB 2.0? (Choose all that apply.) ^ 

Q A. Local home interfaces for message-driven beans. - MP^ S 

Q B. Dirty detection mechanisms to reduce memory footprints. - »r>idc, bu*t ⑽七 ^uav-3h"tccd 


C. Run-as security identity functionality. 


^ D. The JDBC 2.0 extension. 

□ E. Session bean failover. - wyb c availably bu*t ho *t 


3 


Which are features in EJB 2.0? (Choose all that apply.) 


A. Portable finder query syntax. 


2 b. Container managed persistence. 

^ C. Local interfaces for session beans. 

D. XML based deployment descriptors. 

口 E. Synchronous message-driven beans. - AlDBs always 


(s_: 
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2 circjiiteoturcll pVerVieW 




♦ EJB Architecture 


w 



It all looks so 
impressive from this 
view. Too bad we can’t 
stay at this level... 


EJB is about infrastructure. 丫 our components are the building blocks. With 
EJB, you can build big applications. The kind of applications that could run everything 
from the Victoria’s Secret back-end to document-handling systems at CERN. But an 
architecture with this much flexibility, power, and scalability isn’t simple. It all begins with 
a distributed programming model, where clients, servers, and even different pieces of the 
same application are running who-knows-where on the network. But how does the client 
find a bean? How does the client call methods it? Why are there different bean types? Will 
Ben marry J-Lo? 


this is a new chapter 
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no objectives 



Sac^c/no(McC 


We’re in this chapter for background, not because of an exam 
objective. Although, you could say that every objective in the 
exam depends on your understanding what’s in this chapter. 

But don’t worry, well have plenty of objectives beginning 
with Chapter 3. By Chapter 6, you will look back longingly on 
this chapter and remember what it was like not to have any 
objectives. You’ll miss this chapter when it’s gone, so savor the 
moments you have with it. 
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architectural overview 



mivatlc otMs, htrt 



A ridiculously high-level view of EJB architecture 


You remember this picture... 

But it was too high-level to get us anywhere. Think about how much is 
missing from this picture. Like, how does the client get a reference to 
something running on a different machine? How does the client actually 
communicate with the bean? How is it that the server can step into the 
middle of a client-to-bean method call? 

Beneath EJB, there’s java’s distributed technology for Remote Method 
Invocation (RMI). Although EJB hides some of the complexities of RMI 
from the bean developer, it’s still there, and unless you truly understand it, 
some pieces will never make sense. 

So, we start our descent from a high-level view to the blood and guts of EJB 
with a lesson on RMI. If you’re one of the fortunate whoVe already worked 
a lot with RMI, you can skip this and go straight to the part where we talk 
about the ways in which EJB uses RMI. But you should still at least skim it, 
even if you’re an experienced EJB developer, if for no other reason than to 
get comfortable with the terminology and pictures we’ll use throughout the 
rest of the book. 

OK, back to where we started — what’s missing from this picture? Start by 
looking at the places where a miracle occurs... 


-too sooy \ *fco tell s 

a V\CV*C, tut 
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remote methods 


Making a remote method call 


When you write a client to access a bean, the client is either local 
or remote. A local client means the client is running in the same 
JVM as the bean. In other words, both the bean and the client 
live in the same heap. We’ll talk about that much more in the 
Client View chapter, but for now, remember that local means 
same heap/ JVM. Chances are, you’ll use local clients only with 
entity beans, and only under very special circumstances. 


Widi 5ML your client object 
gets to act like it's making a 
remote mefiiod call. But vA&t 


You’ll use a remote client when you want a bean to be used by the 
outside world. Most enterprise applications have a remote client, 
even if some of the beans used in the application talk to one 
another as local clients. (We’ll explore every gory detail about 
this before the book is over.) 


So how does an object in one heap/JVM directly call a method 
on a reference to an object running in another heap/JVM? 
Technically, it’s not possible! Java references hold bits that don’t 
mean anything outside the currently running JVM. If you’re an 
object and you have a reference to another object, that object must 
be in the same heap with you. 


it’s really doing is calling a 
mediod on a ‘"prox/ object 
running in the same Heap 

client. The proxy is 
called a “stub”, and it Handles 
all the low-level networking 
sockets and streams. 


Java RMI (Remote Method Invocation) solves this problem by 
giving the client a proxy (called a stub) object that acts as the 
go-between for the client and Remote object. The client calls 
a method on the stub, and the stub takes care of the low-level 




communication (sockets and streams) with the Remote object. 


Client heap 


o^e\AdviceQ 


o, J a Ual W ㉟ — a 

晰 ihe hcWk) J ^ ( U)r) ，h sc ^s i h 4 


heap 


TV Remote Object is ihc ohje^i with tU 
ythod "that actually docs -tKc v-c^l wov^k 
•fov wha-tcvcv that method is supposed -to ( 
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architectural overview 


There's a "helper" ow the server as well... 

The Remote object has the method the client wants to call. But when the stub 
makes a network connection to the server, something on the server has to take the 
information in the incoming stream and turn it into a method call on the Remote 
object. You could put the networking code into your Remote object, but that 
defeats the whole point of RMI — to make it as easy for your client to call a method 
on an object across the network as it is to call a method on an object in the same 
heap. The goal of RMI is to promote network transparency. In other words, the fact 
that the objects are in different machines should be nearly transparent to the 
developer. Which means to you... less code — simpler code. 

So, with that as the goal, RMI takes care of the server-side of the method call as 
well. The thing on the server-side that accepts the socket connection is called a 
skeleton. It’s the counterpart to the client stub. In the early versions of RMI, for 
every stub there was a matching skeleton object. Today, though, that’s not always 
true. The functionality of the skeleton has to happen somehow on the server-side, 
but an actual skeleton object is optional. We won’t go into any of the details because 
it doesn’t make any difference to us with EJB. How the container chooses to 
implement its skeleton behavior is up to the vendor. 

All we care about is that something is on the server that the stub knows how to 
talk to, and that something knows how to interpret the message from the stub and 
invoke a method on the Remote object. 





method on 


^Adv/ce^ 







Server heap 


^ofe 


Kcr^oic object ii's just a r^cihod ca\\ 
aho-thev- objed*t m the same heap. 
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EJB architecture 



How can you have '"network transparency”? 
What happens if the network or the server is 
down when the client calls the remote method? It 
seems like there’s a LOT more that can go wrong 
than if the client object is just making a plain old 
method call to another object in the heap. 

A- 

Yes, yes. You obviously understand that 
"network transparency” is not only a myth, it’s a bad 
idea. Of course the remote method call can fail in 
ways a local method call would not, and the client 
needs to be prepared for that! 

That’s why, in Java RMI, all remote methods must 
declare a java.rmi.RemoteException, which is a 
checked exception.That means the client has to 
handle or declare the exception. In other words, 
the client can’t really pretend the method call isn’t 
remote. 

But wait, there’s more — the client has to do 
something special to even get the reference to the 
Remote object in the first place. And what exactly is 
that reference? It’s really a reference to the Remote 
object's proxy — the stub. 

So no, RMI does not give you true network 
transparency.The designers of RMI want the client 
to acknowledge that things can go horribly wrong 
with a remote method invocation. 

Still, when you look at everything that needs to 
happen to make a remote method call (networking 
Socket connection, streams, packaging up 
arguments, etc.), the client has to do only a couple 
of things: use a special lookup process to get the 
reference to the remote object, and wrap remote 
method calls in a try/catch.That's pretty trivial 
when you consider what it would take if the client 
had to manage the whole process. 

(And there’s even a way to make it easier for the 
client, using an EJB design pattern we’ll see in the 
last chapter). 


Am I responsible for building the stub 
and the skeleton? How does the stub /mem what 
methods my Remote object has? For that matter, 
how does the client know what methods my 
Remote object has? 

A- 

No, you don’t need to make the stubs and 
skeletons. With plain old RMI, you use the RMI 
compiler (rmic) to generate them. But for the other 
two questions", we’ll let you think about it for a 
minute before we look at the details. 





In Java, what’s the best way to tell the client 
what methods she can call? In other words, 
how do you expose your public methods to 
others? 


Think about the relationship between the 
stub and the actual Remote object. What 
must they both have in common? 


(We II see the answer several pages from now) 
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What about arguments and return values? 

Remote method calls are just like local method calls, except for the 
RemoteExceptions. And what good would a method call be if you 
couldn’t pass arguments or get a return value? You might as well be 
doing RPC*, the way your parents did. 

This brings us to one of the key jobs for the stub and the skeleton (or 
whatever is doing the skeletonish things) — packing and unpacking 
values shipped over the wire. 

Remember, the client is really calling a method on the stub, and the 
stub is local to the client (i.e. in the same heap). So, from the client’s 
perspective, there’s nothing special about sending arguments with 
the method. It’s the stub that does all the dirty work. The stub has to 
package up the arguments (through a process known as marshalling) 
and send them in the output stream, through the Socket connection 
with the server. 

The skeleton-thing on the server has to process the stream from the 
stub, unpack the arguments, figure out what to do with everything (for 
instance, which method to call on which object), and then invoke the 
method (a local call) on the Remote object, with the arguments. 

Then it all happens in reverse! The skeleton packages up the return 
values and ships them to the stub, who unpacks them and gives them 
to the client as plain old garden-variety return values. But in order to 
send arguments and return values, they must be primitives, Serializable 
objects, an array or collection of primitives or Serializable objects, or a 
Remote object. 


The stub and skeleton 
are in it for the whole 
round trip. They’re both 
responsible for packing 
and unpacking the values 
shipped over the wire. 

But it won 9 t work if the 
arguments and return 
values aren’t shippable. 

Shippable values must be 
one of these: 

Primitives 

^ Serializable objects 

^An array or collection 
of primitives or 
Serializable objects 

^ A Remote object 




Client 






丁 he skeleton (o\r is do'm^ *tKc skclc*fcoh 

bchaviov Oh the sewev) Uhjwks method 
avgur^chts ihc Remote obje^i method ca\\, 
p^dks ^Y\d ships *tKc V"c*tuvh v^luc. 


Remote object 


Jon ,f -X skeleton 


Server 


*RPC stands for Remote Procedure Call. Boring. 
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passing objects remotely 


Wait a minute... Java 
passes objects by passing 
a copy of the object reference 
not 


the object itself. 


can 


THAT ever work with a remote 
method call? That reference 
wouldn’t mean anything on 
the other heap... 



In ordinary local method calls, Java 
passes an object reference by value. 
In other words, by copying the bits in 
the reference variable. 


The object itself is never passed. 

1^°^ ^oi ^ J as a 

So … eihihg I 0h heap. 


c. 



void go() { 

Dog fido = new Dog () ; ^ 一 - 

this . trainPet (fido); 


_七 ame 代心一?？ 


We know you know all this, 
obviously, but just so ‘we’re all 
on the same page’ (which is 
an odd thing to say, since we 
clearly ARE all on the same 
page) but you get the idea. 



do^>Y o( ttc V-C-fcV"Cn^C ( 七 V-Crwo-tc 匕 oyrbrol), 
灼。七 P05 object 


void trainPet (Dog arg) 


f 跡 
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What really gets passed whew you 
pass aw object to a remote method? 



Imagine this CLIENT code: 


try { 

Dog fido = new Dog (); 


^ yrcallY ?ass*m^ V^C^rC?? 

remoteStub. trainPet (fido); 


catch(RemoteException ex) 
ex.printStackTrace (); 


Oog 
' object 


And this REMOTE method: 


void trainPet (Dog arg) { } 



⑽ T 七 k rcWw vaW! 
I^s a scr.al^a 


If your remote method 
has an argument 
that’s an object type, 
the argument is 
passed as a full copy 
of the object itself! 

For remote calls, 

Java passes objects 
by object copy, not 
reference copy. 

A serialized copy of 
the object is shipped 
to the Remote object. 




TV^c server Po^'»s d to^ 
d 七 k cWt^i Po^ 


Serializable 


Dog 


Dog implements 
Serializable 
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Getting the object argument from 
the client to the server 


① Client invokes trainPet(myDog) on the 
stub, passing a copy of the reference to 
the Dog object. 



② The stub makes a serialized copy of 
the object and sends that copy over 
the wire to the skeleton. 
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Unpacking (deserializing) the 
object on the server 


③ The skeleton deserializes the passed 

argument, creating a new Dog object in the 
Remote object’s heap. 



④ The skeleton invokes the method on 
the Remote object, passing a plain old 
Java reference to the new Dog object. 



The hcv/ 
° hC Oh i 


以: & ^ 






is 
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^Lerei^ireJiP 

Dumb Questions 


I'm sitting here with a HashMap full of 
Serializable Customer objects with String keys. 

Do I have to worry about whether the HashMap 
itself \s Serializable? 

A- 

^\ m OK,this is kind of a tricky one. All of the 
Collection implementations in the J2SE API are 
Serializable. So you don’t have to worry about a 
Hashmap — as long as what you put in the Hashmap 
is Serializable, you’re fine. 

But... there is one place where things can fail. 
Chances are, you’ll never see this, but it’s still worth 
mentioning. You probably already know that the 
Map classes like HashMap and Hashtable have a 
values。method that returns a collection of just 
the values, without the keys. In other words, if you 
called it on your HashMap, you’d get a Collection of 
Customer objects. 

But what type of collection? And there’s the 
problem. You don’t know. All you know is that 
it’s something that implements the Collection 
interface. But that isn’t enough to tell you whether 
the Collection returned by valuesO is Serializable! 

In other words, you might get back a Collection 
that —— even when filled with Serializable objects — is 
not itself Serializable! 

The bottom line: don’t rely on the Collection 
returned from a map’s values!) method to be 
Serializable. Put your values into something you can 
trust to be Serializable, like ArrayList, before trying 
to ship them as part of a remote method call. 


If something you’re passing to a remote 
method isn’t Serializable, is this a compile-time or 
runtime failure? 

• Runtime! Usually, anyway. Remember that the 
declared argument or return type is not necessarily 
the same as the actual runtime type. 

The only case where it can fail at compile time is if 
the remote method actually uses Serializable as the 
declared type of the argument or return value: 

public void takelt(Serializable s); 

In that circumstance,the compiler can use normal 
Java type-checking to see if the declared type of the 
thing being passed implements Serializable. 

Most of the time,the declared argument or return 
type is something other than Serializable (like Dog, 
ArrayList, String, etc.), so Java won’t know whether the 
runtime object is Serializable until it actually tries to 
do the serialization (and then it throws an exception). 

And with collections and arrays, if any of the objects 
inside aren’t Serializable, the whole serialization fails! 

Does my class have to explicitly implement 
Serializable, or can I inherit Serializableness from my 
superclass? 

A- 

Remember Java’s IS-A rule: if your parent 
(superclass) is something, then so are you. If Dog 
extends Animal, and Animal implements Serializable, 
then Dog is Serializable whether the Dog class 
explicitly declares it or not. 

However, it is considered good practice to explicitly 
declare your class as Serializable even if your superclass 
does, just so that others looking at your class API don’t 
have to hunt through your class’ inheritance tree to see 
if somebody up there is Serializable. 
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Remember，arguments and 
return values for a remote 
method must be one of these: 


Primitives 

^ Serializable objects 

+An array or collection of primitives 
or Serializable objects 

^ A Remote object 


I don’t get why ifs legal 
to pass a Remote object in a 
remote method! Isn’t the whole 
point of a Remote object to stay... 
remote? Why would you send a 
Remote object to the client?? 
That makes no sense. 



(ill make sense m a 
Bu*t bc-fovc you 七 u\nr\ 七 
page, 七 iVmk about "tKc 

o-f pdss'm^ d 

Remote object a 

od 乙 all … 


you are here ► 


73 


remote method arguments 


Passing a Remote object through a 
remote method call 


It does not make sense to send a Remote object in a 
remote method call. After all, the whole point of a 
Remote object is to stay remote. To be accessed by 
clients who live... somewhere else. In another heap. 

But what if you want to pass a remote client a 
reference to another Remote object? What if, 
rather than handing your client a full-blown copy 
of a Customer, you send him a stub to a Remote 
Customer? 

Think about it. Before you read the next page. 





What are the implications of passing a stub to a 
Remote Customer object as opposed to passing a 
non-remote Customer object? 


犧 en you pass a Remote 
object to or from a remote 
mediod, Java actually sends 
ilie Remote object’s Sfab. 

In odier words, at runtime, 
ihe Remote object stays ri^it 
wdiere it is, and its Stub is 
Sent over ike wire instead. 






What are the benefits of passing a stub instead of 
the real Customer object? 


What are the drawbacks? 


(Note: whether to pass serialized objects or stubs 
to remote objects is a crucial design decision. We’ll 
explore this when we look at performance and 
patterns.) 



\ota\ 

toasts 
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When the return value is a 
Remote object... 



Remote object A returns a reference to a 
Customer object (Remote object B). The skeleton 
substitutes (and serializes) the Remote object’s 
stub, and sends it back to the client. 

The Customer stub (B) is deserialized on the 
client, and the client gets a local reference to the 





new stub object 


local reference ^ 
to stub B (stub B 


Customer 




object (B). 
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RMI questions 


^liereiEireriP 

Dumb Questions 


What happens if the client object and the 
Remote object are running in different JVMs, but 
on the same physical machine? In other words, 
they’re both running in Java programs on the same 
server? 


A ： 


Doesn’t make any difference. All that matters 
is whether the two objects live in different heaps, 
and JVMs do not share heaps with one another, thank 
you very much, no matter how intimate they are 
(cohabiting the same server). 

In fact, you can (and with EJB often must) use RMI 
even when the objects are in the same heap. 

Why in the world would you ever want to do 
use RMI if you don’t need to? Isn’t there enough 
overhead with remote calls as it is? 


A ： 


We’ll go into this in more detail later, but 
the main reason is because if you don’t use RMI for 
method calls, you’re locking down your design in 
such a way that you can’t distribute your objects in 
different places in your network (or even on the same 
server). In other words, without RMI, you must have 
both objects in the same heap. 

For a distributed programming model, that’s a pretty 
permanent decision, with no chance to change your 
mind later, without rewriting code. On the other 
hand, if you do use RMI, you can decide later to split 
your program up into different nodes on your system, 
with little or usually no code changes. 

So the tradeoff is flexibility for performance, but for 
most distributed enterprise apps, the overhead of a 
remote call is not your biggest problem. It’s usually 
your bandwidth and/or concurrency that hurts the 
most. Overall, you probably have bigger performance 
fish to fry in areas of/ierthan whether your calls are 
remote or local. But the story isn’t always that simple, 
so we’ll explore this again later in the book. 


BULLET POINT 



■ 


■ 


■ 


■ 


■ 


■ 


■ 


■ 


■ 


■ 


EJB uses Java RMI (Remote Method Invocation) so 
that your beans can be accessed by remote clients. 

A remote client, in this context, is an object running in 
a different JVM, which also means a different heap. 

A Remote object stays in its own heap, while clients 
invoke methods on the Remote object’s proxy, called 
a stub. 

The stub object handles all the low-level networking 
details in communicating with the Remote object. 

When the client wants to call a method on a Remote 
object, the client calls the same method on the stub. 
The stub lives in the same heap as the client. 

To the client, a remote method call is identical to a 
local method call, except a remote method can throw 
a RemoteException (a checked exception). 

The stub packages up the method arguments and 
sends information about the call to a skeleton on 
the server. The skeleton object itself is optional, but 
the skeleton’s work must be done by something on 
the server. We don’t have to care who—or what—is 
actually doing the skeleton’s work. 

Arguments and return values must be one of the 
following: a primitive, a Serializable object, an array 
or collection of primitives or Serializable objects, or a 
Remote object. If the value isn’t one of these, you’ll 
get a runtime exception. 

If an object is passed as an argument or return 
value, the object is sent as a serialized copy, then 
deserialized on the Remote object’s local heap. 

If a Remote object is passed as an argument or return 
value, the object’s stub is sent instead. 
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Oh my! I almost forgot the 
most important thing about remote 
method calls! When you pass a serialized 
object as an argument or return value, you 
better make sure the class file for the type 
you re passing is available on the other 
side. If the class isn’t there, the object 
will never deserialize and 
you re screwed! 




That includes the stub 
classes. If the client 
doesn’t have the class for 
the stub object, it’s 
hopeless. 
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What must the Remote object 
and the stub have in commow? 


How does the client know which methods to call? 

How does the stub know which methods the 
Remote object has? 

Remember, if the stub is pretending to be the 
Remote object, the stub must have the same 
methods as the Remote object. 

Of course you know the answer to this. 

An interface. 

The way all methods in a distributed environment 
should be exposed to a client. 

We call this the business interface because it has 
the business method(s) the client wants to call. 
Technically, the business interface for a Remote 
object must be, surprisingly, a Remote interface. 


To be Remote, an interface must follow three 
rules: 

^ it must extend java.rmi.Remote 

^ each method must declare a 
java.rmi.RemoteException 

^ arguments and return types must be 
shippable (Serializable, primitive, etc.) 


It all begins widia Remote 

Bodice Remote 
object and the stub implement 


interface. 


ilie same interface... the one 
wifli the mefliods ilie client 
wants to call. 


A Remote interface must 


extend 


java.mi.Reinote 


and 


every mefiiod vmst declare a 


RemoteException. 







import java. rmi. - ； -- s/ , 

^ 一 、 > w!v!°docs^b methods) 

public interface DiceRoller extends Remote { (.>wn»6n 


public int rollDice() throws RemoteException; 


All o( yowr mctKods must dcdlavc 
a RcmotcExdcp-tioh. 
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The client calls business methods 
on the stub through the Remote 
business interface 

Remember, as far as the client’s concerned, he’s calling 
methods on The Real Thing. The actual Remote object. The 
thing that has the methods he wants to call. 

The only thing reminding the client that he isn’t 
calling methods directly on the Remote object is the 
RemoteExceptions he has to deal with. 


"th s£ub tlass 




《 interface 》 

DiceRoller 




rollDice() 


i\\t Remote 

(fevAsmcss) 




✓ \ 

〆 \ 

〆 \ 
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EJB architecture 


lharpen your pencil 


This yts you oh *thc oy\C r^ost dommoh 

mis-takc EJB dcvclopcvs r^ake. So do〆 七 skip i 七 | 


Based on this scenario, draw the classes below into the 
appropriate slot for whether they must be on the client, server, or 
both (you can reuse a class). The picture is simplified, so you 
aren’t seeing all of the players involved. 






101101 ^ 
101101 
10101000010 
1010 10 o 
01010 1 
1010101 
10101010 
1001010101 


DogTrainerlmpI 


101101 
101101 
10101000010 
1010 10 0 
01010 1 
1010101 
10101010 
1001010101 


101101 ^ 
101101 
10101000010 
1010 10 0 
01010 1 
1010101 
10101010 
1001010101 


DogTrainerStub 


DogTrainer 

interface 


101101 
101101 
10101000010 
1010 10 0 
01010 1 
1010101 
10101010 
1001010101 


client class 


101101 ^ 
101101 
10101000010 
1010 10 0 
01010 1 
1010101 
10101010 
1001010101 


Dog 
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How EJ? uses RMI 


In EJB, a client’s entry point into the 
enterprise application is nearly always 
through a reference (stub) to a Remote 
object. Yes, it is possible, and sometimes 
necessary, to use a local client (i.e. a 
client in the same heap as the bean, and 
which doesn’t use RMI to invoke business 
methods), but this is for only a few very 
special cases. 


So RMI lies at the heart of most client-to- 
bean communication. But as you saw a hint 
of in the first chapter, the EJB architecture 
is a little more complex than a simple 
client-to-stub-to-Remote-object scenario. 

In EJB, the bean — the thing on which the 
client wants to call business methods — is 
not Remote! 


Plain RMI 


^us'mcss \oyt 
|Wcs 




you are here ► 


81 










































EJB object 





'y' e ^ 




EJB server 



The Remote object is wot the bean it's 
the bean's bodyguard—ihe EJPObjeef 

In EJB, remember, the Remote object (EJBObject) is the 
bean’s bodyguard. The bean sits back, protected from all 
client invocations, while the EJBObject implements the 
Remote interface and takes the remote calls. Once the call 
gets to the EJBObject, the server jumps in with all the services, 
like security (is this client authorized to call this method?), 
transactions (is this call part of an existing transaction, or 
should we start another transaction?), and persistence (does 
the bean need to load info from the database before running 
the client’s method?). 

The EJBObject implements the Remote business interface, so 
the remote calls from the client come to the EJBObject. But 
it’s still the bean that has the real business logic, even though 
the bean doesn’t implement the Remote interface in the 
technical Java way. 


Nobody talks to the 
bean without going 
through me first. 


Bodiilie Remote object 
and^ie stub implement ike 
same interface-die business 
interface (called a Component 
interface)-but widioutilie 
real business logic behavior. 

The bean class does NOT 
implement ike business 
interface (in ike formal 
Java way), hxt the bean 
liasilie real business logic 
fimcfionality. 




30DM-J3+-UI ziq 
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The Component interface 

In EJB, the business interface is called the component 
interface. This is where you expose your business 
methods to the client. The main difference between 
an RMI interface and a remote component interface 
is that with EJB you extend javax.ejb.EJBObject 
instead of java. rmi. Remote. 


Key points: 


① 


Any interface with java.rmi.Remote in its inheritance 
tree is a Remote interface. 


The EJBObject interface extends Remote, so 
EJBObject is a Remote interface. 


® Your remote component interface must extend the 
EJBObject interface. 

(You can have a local component interface, and the 
rules are different, but we’ll look at that in the chapter 
on Client View.) 


《 interface 》 

Remote 


f\\\ Remote 


《 interface 》 
EJBObject 

//several methods 


^ y。: 


《 interface 》 

BookCart 


addBookf) 

removeBookf) 

showBookslnCart() 

doCheckoutf) 


c\^i vascs! 


/Tn You expose your business methods to the client 
through the component interface. 


The EJBObject interface adds additional methods for 
the client to use. (We’ll see those later.) 


Whoever implements the BookCart 
interface must implement all the methods 
from both BookCart and EJBObject The 
EJBObject interface adds the methods 
that all EJB clients might need. 
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the bean class 


How the bean class fits in 


(J2SE API) 


(J2EE API) 


YOU write this 
interface 

(the remote 
component 
interface) 



(J2EE API) 


(J2EE API) 


YOU write this 
” class 


(the bean class) 


You REALLY 
have to know 
the interfaces! 

The exam expects you to know 
exactly where each method lives. 
You need to know which methods 
are in EJBObject, and which are 
in SessionBean, for example. 
And you hsve to know the exact 
signature for those methods. 
We , ll get into these interfaces in 
the next couple of chapters, and 
when we do, pay attention! 




BooH i ihe 

l (hui ^ ^ looks r lke ii does _j 

TKc dcvclopcv must make su\rc 七 

七 he bean £.lass V^as mc-tiiods 七广 *0^ 
methods m tKc C^tly 

as *»-f i\\t be 扣 ^lass P|P tV^c 

tomfo 灼⑶七 
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^JiereiSireriP 

Dumb Questions 


I just want to be sure I’m clear about this 
interfaces can EXTEND other interfaces? 


A 


9 

m 


Yes, interfaces have their own inheritance tree. 


In fact, with interfaces, you can do something you 
can’t ever do with a class — an interface can extend 


more than one interface! 


interface Cart extends EJBObject,CartBusiness 

But what does that really mean when an 
interface extends another interface? Extending 
means inheritance, but what is the interface 
inheriting? 

A- 

厂 When one interface extends another, it 
inherits everything from that interface. Whoever 
implements an interface must implement not just the 
methods from that interface, but also the methods 
from every interface that interface extends... all the 
way up the interface inheritance tree. 

So, in this example, whoever implements BookCart 
must also implement the methods of EJBObject. 


When you implement 
an interface, you must 
implement all the 
methods that interface 
inherits from its super- 
interfaces. 

So whoever implements 
BookCart must implement 
the methods from both 
BookCart and EJBObject. 


Why doesn’t the bean implement the 
Remote/business interface? Isn’t the whole 
point of an interface implementation to use the 
compiler to keep you honest, and to support Java 
type-checking? 

A- 

You asked this question before. But, hey, 
we all forget things, so we’ll remind you again.The 
bean doesn’t implement the Remote interface 
because the bean is never supposed to be a 
Remote object (in the Java RMI sense). In other 
words, you never ever want anyone to have a stub 
to the actual bean! If you were to somehow sneak 
a remote reference (i.e.a stub) out to the world, 
you’d be defeating the whole purpose of EJB! If you 
let a client talk directly to the bean, then the server 
wouldn’t be able to apply its services, and if you 
don’t need the services... you see where we’re going 
here. 

Technically, it is legal to have the bean implement 
the Remote interface, but it’s a really bad idea, since 
you could make mistakes that wouldn’t be caught 
at compile time (but which would blow up later). 
But you don’t need to do it, since virtually all bean 
development tools (including nearly every bean- 
aware IDE) understand the relationship between 
the bean,the EJBObject, and the Remote interface, 
and they guarantee that the component interface 
and the bean class have matching methods. 


But what if I just find this too disturbing? 
This whole idea violates my Java sensibilities, the 
very principles upon which I code. Surely there 
must be something I can do? 

A- 

You could trust us on the whole "you’re 
almost certainly using tools, so it really won't 
matter. Really”thing, but no... so if you insist, yes 
there is something you can do that’ll probably help 
you feel better. It’s on the next page, but you can 
probably figure it out yourself anyway. 

Nonetheless, we’re sticking by our story that most 
developers won’t need to do this. 
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A design for those who feel 
squeamish that the bean 
doesn’t implement the 
business method interface... 
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So, I write my bean and 
I put in matching methods 
from the component interface, 
without officially implementing 
the component interface. But if 玉 
don’t implement the component^ 
interface... who does? 



Who writes the class that really POES 
implement the component iwtcrfacc? 
Iw other words, who makes the 
EJPObjcct class? 


The container. You declare the methods, but the container 
implements your component interface. Remember, your 
component interface is the one that extends EJBObject, so the 
container has to implement not just your business methods, but 
also the methods of EJBObject (which we haven’t yet looked at). 


But how does the container know what to put in those 
methods? I’m the one who declared those methods... 

A. 

jr Y m Remember, the container isn't implementing the real business 
logic.The true functionality for those business methods lives in your 
bean class — the class that you implement.The class implementing the 
component interface is going to be the EJBObject.The bodyguard.The 
Remote object. And remember that the EJBObject is only pretending 
to be the bean. It can respond to the remote method calls conning from 
the client (via the stub), but the EJBObject’s only job is to capture the 
incoming client calls to the bean. After that, it’s up to the container/ 
server to take over. 

We don't really know how the EJBObject is implemented — it’s 
completely up to the vendor. But we don’t really care. All you need to 
know is that an EJB container is required by the spec to generate the 
code for the EJBObject (and its corresponding stub). 
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Who creates what? 

For a bean with a remote client view (in other words, a bean that can be accessed 
by remote clients), you know that you have to write the Component interface and 
the Bean class. But somebody has to write the class that implements your Component 
interface (to make the Remote EJBObject), and somebody has to make the stub that 
goes with that EJBObject. That somebody is the Container. And, though we haven’t yet 
talked about the Home, we’ve listed the relevant pieces here for completeness. 


You 

(T) The Component interface 

(extends javax.ejb.EJBObject) 

(2) The Bean class 

(implements javax.ejb.SessionBean 
or javax.ejb.EntityBean) 


the Container 

O The EJBObject class 

(implements your Component interface) 

( 5 ) The EJBObject stub class 

(implements your Component interface 
and knows how to talk to the EJBObject) 


(§) The Home interface 

(extends javax.ejb.EJBHome; we’ll 
talk about this on the next page) 




(§) The Home class 

(implements your Home interface) 


(4) The Home stub class 

(implements your Home interface 
and knows how to talk to the Home) 
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EJBObject: Hey Beanie...dont you ever get tired of 
always having me in the middle of everything? Don’t 
you ever just want to have a direct conversation with 
someone? 

Bean: No. I'm too important. I’m too valuable. And 
I'm sure as hell not gonna start screening my own calls. 
That's what you people are for. 

EJBObject: You people? 

Bean: Yeah, you people who work for the container. 
You, the Home, the stubs, all of you. My job is to handle 
the complex business logic. The critical functions that 
mean the difference between success and failure in an 
enterprise environment. 

EJBObject: (Qzzz, sounds like a marketing speech). 
OK, so you have some important methods, but I still 
don't see why you need to have me in every call. 

Bean: Look, my work is too important to be 
interrupted by clients who have no business calling me 
in the first place. Do you honestly think that I am going 
to check security clearances for every caller? Like I 
don’t have better things to do? 

EJBObject: OK, so if s really just a security thing, but 
I don’t see why you can't just have the code to check 
the security access of the caller. That would save a lot 
of overhead (namely, ME). 

Bean: First of all, security is just ONE of the reasons 
you have to take my calls. I'll get to those other 
reasons in a minute. But as for putting in code to do my 
own checks, actually I CAN do that, if the programmer 
wants me to. But it’s usually not the way to handle 
security. 

EJBObject: Whafs wrong with you handling the 
security checks in your own code? 

Bean: You really don’t know, do you? [rolls eyes] First, 
if the security checks are coded into me, then I'm not 
as reusable. The whole point of EJB is to configure and 
customize beans at runtime, without rewriting the code. 
If Ive got security programming in my Java code, then 
it cant be changed without touching the source. And 
who wants that? 


EJBObject: I guess that makes sense. You put the 
security checks in the XML deployment descriptor, and 
then when I get the call, the server can check to see 
if the client has the right authorization. But what if 
security isn’t even an issue for you? What if whoever 
deploys you doesn’t care who calls the methods? 

Bean: Not too bright, are you? But at least you can lift 
heavy objects... THINK about all the other things that 
matter, like transactions and persistence. 

EJBObject: Oh, I forgot about transactions. OK, that 
makes sense too. The server has to figure out if there's 
a transaction context before it calls your method so 
that your method can run in a transaction. Either your 
own, or the callers... 

Bean: Duh. 

EJBObject: But where does persistence come in? 

Bean: Well, think about entity beans for a minute. If 
I'm an entity bean .that means I'm representing some 
entity in the underlying persistent store and— 

EJBObject: —wait—by persistent store, don't you just 
mean DATABASE? Why dont you just say database? 

Bean: Uh, newsflash, the word phrase ''persistent 
store" is not a synonym for ''database”. A database is 
just one example of a persistent store. But if it makes 
you feel better to think about it that way, go ahead for 
now. But as I was saying, if I represent an entity, say, 
a customer named Tom Duff, then what happens if the 
client calls my getAddress() method? The server can’t 
just hand me the call! 

EJBObject: Because... 

Bean: Because I have to load in Tom Duffs 
information from the database first! 

EJBObject: Because... 

Bean: Because I’d return an address that might not 
even be valid! Unless I'm still in a previous transaction 
with this client, then the server has to tell me to 
load myself with Tom Duffs database info BEFORE 
the server tells me to run the getAddress() method. 
Otherwise, who knows what I'd return? OK, well, that’s 
last call, so well have to continue this some other time. 
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How and when does the 
container create the EJBObject and 
the Home and the stubs? 

When you deploy a bean, 
the container looks at the DD and 
takes it from there. Remember, the 
DD gives the fully qualified name of 
your Remote Component (EJBObject) 
interface and your Remote Home 
interface. So, once the container gets 
those interfaces, it generates code 
for the two classes implementing 
those interfaces. And because they're 
Remote, the container also creates 
the client stubs that know how to 
communicate back to the Remote 
objects. 

Are these always plain old RMI 
stubs? I see that when we deployed 
using the Rl, it printed out a message 
that it was running rmic … 

The container can do what¬ 
ever it wants to create the stubs; the 
requirement is that the stubs be RMI- 
IIOP compliant. In fact, a server can 
use something called dynamic proxies 
to implement the stub functional¬ 
ity, but we don't care. When we say 
"stub” we mean something with stub 
behavior. Whether it’s an RMI stub or 
something else, is an implementation 
detail for the server. We’ll look at that 
in more detail in the next chapter.The 
bottom line is that you really don’t 
know what the stub class code looks 
like. For that matter, you really don't 
know how the EJBObject and the 
Home are implemented. You’re not 
supposed to know. 

You might have an EJB container that 


tLereicirenP 

Dumb Questipns 

lets you view (possibly even hock) 
the generated source code, but don’t 
count on it. And if we were you, we 
just wouldn’t go there, even if we 
could. 

So these classes are up to the 
vendor’s implementation? 

Yes! The vendor has all sorts 
of choices for implementing these 
classes and might use the stubs and/ 
or Home and EJBObjects to get some 
performance advantages. But again, 
that’s not up for you to mess with, or 
even know about. 

The only requirement in the spec 
that you’re guaranteed (and required 
to adhere to) is that Remote objects 
must follow the rules for RMI-IIOP, 
which means Java’s Remote Method 
Invocation using the MOP (CORBA 
standard) wire protocol. 

You brought it up: how is RMI- 
IIOP different from regular RMI? 

Plain old RMI uses JRMP as its 
wire protocol. But NOP lets Remote 
objects interoperate through CORBA 
(we won’t be saying much at all about 
CORBA in this book; it's definitely out 
of scope for the exam and the book, 
except in a few tiny cases we’ll see 
scattered throughout the chapters). 

That gives your objects a chance to be 
accessed, for example, by even non- 
Java clients. One thing NOP specifies is 
the way information for transactions 
and security can be propagated 
along with the method call, and your 
container might be taking advantage 
of that. 


For the most part, you’ll barely notice 
the difference between plain old RMI 
and RMI-IIOP. But... there are a couple 

of places where it’s different, and one 
of these differences is definitely on 
the exam — the need to narrow a stub. 
We’ll cover narrowing in detail in the 
next chapter on Client View. For now, 
just know that it’s something a client 
must do with an EJB stub that they 
don’t have to do with a plain Java 
stub because the EJB spec tells you to 
assume that the stub is using NOP and 
thus might be a different kind of stub. 

When are we going to talk 
about the Home? 

Next page. 

Why did you take so long? 

Isn't the Home important? 

As crucial as the Home is, 
it’s usually just the way you get 
a reference to something that 
implements the Component interface. 
In other words, you use the Home to 
get an EJBObject stub (for Remote 
clients, which is all we’ve talked about 
so far). 

For Entity beans, the Home can have 
a more important role, and we’ll see 
that, but even with Entity beans, the 
Home’s primary use is still to get 
EJBObject stubs. After that, most of 
the communication between the 
client and the bean comes through 
the EJBObject and not the Home. 

Most of the time, in fact, clients use 
the Home just to get the EJBObject 
reference, and then the Home 
reference is tossed out, not needed. 
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The bean Home 


Every Session and Entity bean has a Home. 

Message-driven beans don’t have homes because 
message-driven beans don’t have a client view (in other 
words, client’s can’t get a reference to a Message-driven 
bean). 

The Home has one main job: to hand out references to 
a bean’s Component interface. For a Session bean, that’s 
just about all you’ll do with the bean’s Home. For Entity 
beans, though, the Home plays a much bigger role. 

Each deployed bean has its own Home, and that Home 
is responsible for all bean instances of that type. For 
example, if you deploy a ShoppingCart Session bean, 
the container will create one ShoppingCart bean 
Home. That ShoppingCart Home takes care of all the 
instances of ShoppingCart beans. In other words, if 
2,000 clients each want their own ShoppingCart bean 
reference (which, remember, means a reference to the 
ShoppingCart bean’s Component interface), the one 
and only ShoppingCart Home will hand out all 2,000 
references. 

If you deploy three beans as part of an application, say, 
a ShoppingCart, Customer, and Product, there will be 
three Homes in the server representing each of those 
deployed beans. It makes no difference how many 
EJBObjects and stubs the Home objects hand out, there 
will still be only three Homes. 

So does that mean that for each Home there is only a 
single instance of the class that implements the Home 
interface for that bean type? Not necessarily, but that’s 
exactly how we’re supposed to think about it. We’ll 
actually refer to the Home as the Home object ，and we’ll 
assume that there’s always just one per deployed bean 
type. The spec guarantees that you can think about it 
that way, regardless of what your vendor actually does 
with its implementation for the Home. 



EacK deployed Session and 
Entity bean Has a Home. For 
example, ihe A^viceBean Kas 
an AdviceBean IJome. No 
matter Kow many clients get 
an A^viceBean, there’s only 
one A^viceBean IJome. 

The IJome's job is to Hand 
out references to that bean’s 
Component interface. 


(Technically there's a little more to the story 
because a bean might have both a local Home 
and a Remote Home, but that’s really unlikely. 
Even then, there would be only one of each 
Home type (Remote or local) no matter how 
many beans of that type are alive.) 
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(2^ The client does a JNDI lookup on the Home, 
using the registered name “Advisor”. 




'son 0 ) 


Getting and using a Home for the AdviceBean 

(This scenario assumes AdviceBean is a stateful Session bean.) 


The AdviceBean is deployed, and the server 
instantiates the AdviceBean Home object 
and registers it with JNDI. 




JNDI Naming 
Service yx 

''Advisor'" stub 1 




SDM-J3+-U! 3E0 工 
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JNDI Naming 
Service 


Advisor" 




M?) The client asks the Home for a reference to the 
Component interface, by calling create() 

(In other words, the client wants to “create” a bean and 
get the stub back to the bean’s EJBObject) 


^3^ JNDI sends back a stub to 





8DM-J3+-U! 3£0 工 
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the home 


The Home object makes the EJBObject 
and sends back the stub 


( 5 ) Now the ‘‘services’’ kick in, and the bean is created 




(g) The EJBObject is made (the bodyguard for this newly 
created bean) and its stub is returned to the client. 
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The client can get rid of his Home stub if he doesn’t 
want access to more beans of this type (AdviceBean), 
but he can still keep calling methods on the 
Component interface. 


(7) Now, the client can (finally) do what he REALLY wants 
to do — call a business method on the bean! (Which of 
course, has to go through the Component interface.) 





tul 



nt 
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lharpen your pencil 


EJB Lifecycle: 


In the scenario below, assume the client has previously done a JNDI lookup and 
gotten back a stub to the Remote Home object. 

Everything in the picture is what happens AFTER the client has the Home stub and 
now wants to get a reference to an EJBObject and ultimately call a business method 
on the bean. 


Client has only a 
Home stub but wants 
to invoke a business 
method on a bean. 


Number the arrows (using the boxes over the arrows) in the order in which they 
occur. These arrows aren't necessarily direct method calls (although they might be), 
but rather arrows pointing to the next THING that happens. Tell a story for what hap¬ 
pens at each arrow. There might be more than one right answer, depending on how 
you tell the story. Some arrows are missing; you can add them if you want, or, just 
assume some things are happening that you don’t have arrows for. 


Relax and take your time. 

If you get stuck, flip back through the previous pages and study the diagrams. 



2, Tlic stub tells 七 he Home 七 ha 七 "tiic tlieh 七 
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Beans that are exposed to remote clients have two Remote 
interfaces one for the EJBHome and one for the EJBObject. 

A Remote interface must extend (directly or indirectly) 
java.rmi.Remote, and all methods must declare a 
java.rmi.RemoteException. 

In EJB, the interface that extends EJBObject is called the 
Remote Component interface. It is where the business methods 
are declared. 

The client never calls methods on the bean itself because the 
bean is NOT a Remote object. 

The container implements the Remote Component interface by 
building a class that implements it. This class is used to make the 
EJBObject for the bean. (The bean’s bodyguard.) 

The container also creates the stub to the EJBObject. 

You create the Remote Component interface by writing an 
interface that extends javax.ejb.EJBObject (an interface that 
extends java.rmi.Remote). 

You also create the bean class where the actual business 
methods are implemented (despite the fact that the bean class 
technically doesn’t implement the Remote Component interface). 

The Home is the factory for the bean. Its main job is to hand the 
client a reference to the bean. But remember, the client can never 
truly get a reference to the bean—the best the client can do is to 
get a reference to the bean’s EJBObject. 


■ You create the Home interface by writing an interface that 
extends javax.ejb.EJBHome (an interface that extends 
java.rmi.Remote). 

■ The container is responsible for implementing the Home interface 
by building a class that implements it, and the container also 
generates the stub for the Home. 


■ There is only one Home per deployed bean. For example, a 
ShoppingCart bean would have a single ShoppingCart Home, 
regardless of how many ShoppingCart beans have been created. 
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Architectural overview: Session beans 



Clients share the Home, but never the bean. 

Each client gets his own EJBObject reference and his own bean. The client never 
shares a bean with another client, although the meaning of “shares” depends 
on whether the bean is stateful or stateless. (We’ll see that in the next chapter.) 
However, there’s only one Home object for this particular bean type (say, 
AdviceBean), so both clients have a stub to the one and only Advice Home. Both 
clients ask the same Advice Home for a reference to an Advice bean. (Of course, 
the client never gets the reference to the bean instance, but instead gets a reference 
to the bean’s EJBObject. And since EJBObject is Remote, the clients gets a stub.) 



■EJB 

Ibject 


fEJB 

bject 


Server 


Client One 


There's only one Home 
object, but each client 
gets his own dedicated 
bean and EJBObject. 


Client Two 


A session bedh dietvt is guav-a^*tccd h> 
be Ohly a mctiiodi 

oy\ be 扣 . iVliilc *tKc dietvt is ih 
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bedh bclohOs -fco -that dieyrt ， 


98 


Chapter 2 















architectural overview 


Architectural overview: 


Ewiity beans 


Clients share the Home，and may share the bean. 

Each client has his own reference to the one and only Home for this bean (say, 
CustomerBean). But, if two clients are trying to access the same Customer (Fred Smith 
#420), then both clients have a reference to the same EJBObject. The EJBObject for #420. 
In other words, the EJBObject is the bodyguard for a particular Customer (like Fred Smith). 
If all the clients are trying to access Fred Smith #420, they will each have their own stub, 
of course, but all stubs will communicate with the same Remote EJBObject. And there will 
be only one bean representing Fred Smith #420. If a client wants to access two different 
customers, though, the client will have two stubs, and those stubs will be for two different 
EJBObjects, one for each customer. And that also means two different beans. 



Fred Smith's 
bodyguard 


fEJB 

bject 


Skyler San's 
bodyguard 


Client One 


Client Two 


Customer 

table 
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Architectural overview: 

Creating a Stateful Session bean 

After getting a Home stub, the client calls “create” on the Home. 
The Home creates the bean and the EJBObject for the bean and 
hands back the EJBObject stub. 



IEJB 

Ibject 


bean 


1 ■ Tiic 乙 alls tvcatcO ov\ the Home stub (dvca-tcO is a method m 

Home m 七 

2 - TKc stub sends 七 he tv-caicO 乙 all *to 七 lie Remote Home object. 

3 - Tlic Home object steps \ y \ adds its sewites. 

4 - Tlic £JB0bjcd*t is dvea-ted/ms-tah-tiated -fov -the bea^- 

5 - TKc bedh i*Ucl-f is *mst3h*tia*tcd. 

6 - Tiic £JB0bjcd*t stub is vc*tuv-hcd *to dieivt, so the dieh 七乙 扣 乙 all 
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1 ■ The dieht ddl Is Oh tliC Home stub (dvcatcO is d method \y\ tKc 

Home m*tcv--fa^c)- 

2- Tiic stub schds 七 he tv-catcO 乙 all *to 七 he Remote ttomc object. 

3 - Tlic Home ^oh*ta"mcv steps m a^d adds i-ts sev-vites. 

4 - EJBObjc^t is ^v-ca*tcd (or this dieht 

5 - TKc bedh s-tays *m bed^ pool / |*t Co^cs out o^ly *to sewide by\ actual 
business rwc-tiiod, i-f 七 he £>lie 灼七 invokes ov\C oh tJBObjc^t s*tub. 

6 - Tlic EJBObjc^t stub is vc*tuv-hcd -fco *tiic dso 七 he dien 七匕扣乙 all 
business methods ov\ tiiC ComPohCht 


Architectural overview: 

Creating a Stateless Session bean 

After getting a Home stub, the client calls “create” on the Home. The 
Home gives the client a stub to an existing EJBObject but does not 
associate a bean with this EJBObject! Instead, the bean stays in a pool 
until the client uses the EJBObject stub to call a business method. 
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OK, so the bean comes out 
of the pool only when the client 
calls a business method, but then... 
how did the bean get in the pool in 
the first place? If it wasn’t created 
when the client called create(), 
then what did cause the bean to 
be created? 



Who creates the stateless session 
bean, and whew? 

First, we have to define what create means. For a session bean, it 
means the bean instance is physically instantiated and initialized 
as a bean. For an entity bean, it’s completely different, so this 
conversation applies just to session beans. Later we’ll get into 
what it means to create an entity bean. 

For state/^/ session beans, the create is triggered by the client. 
The client calls create on a Home stub, and everything happens 
at that point — an EJBObject is instantiated for this new about-to- 
be-created-bean, and then the bean itself is created and linked to 
the EJBObject (the bean’s bodyguard). 

But for statesession beans, the client create and the actual 
creation of the bean are decoupled. In other words, just because 
the client calls create on a Home stub doesn’t mean a bean will 
be created at that point. 


Stated session beans aren’t created until the container decides 
it needs one, and that’s really up to the container. It might, 
for example, make a bunch of bean instances (i.e. create some 
beans) and plop them in a pool before even a single client 
has asked for one (by calling create on a Home stub). Or, the 
container might make just-in-time beans, and wait until the 
client invokes a business method before going to the trouble of 
physically creating the bean. 
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Stateless session beans arc more scalable 

Clients don’t share EJBObjects, but the same 
bean can service multiple EJBObjects. Just not at 
the same time. A single bean can handle multiple 
clients, as long as only one client at a time is in the 
middle of a business method invocation. 


Client One 


Server 
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Why does the “pool” architecture work to make 
stateless session beans more scalable, but 
not stateful session beans? Why can’t stateful 
session beans use the bean pool? 


tWeiqrenP ^ 

Dumb Questions 

Here's something that is REALLY 
starting to annoy me... why do you have a 
Component interface and a Home interface 
when the Remote objects are called the 
Home and the EJBObject? Why isn't it just 
the EJBObject interface and the HomeObject 
interface? Or the Home and the EJB 
interfaces? Why the inconsistency? 

Actually, that really pisses us off too. But 
you’ll get used to it. Be thankful, it was even 
worse if you learned EJB prior to version 2.0 
when it was called the Home and the Remote. 
Now that was a real problem because, first 
of all, both the Home and the Remote were 
Remote in the java.rmi sense. Second, as of 
EJB 2.0 you can have a Home and a Remote 
that aren’t... actually... Remote. So, they had 
to change the name to Component interface 
instead of calling it THE Remote interface, 
since it might, in fact, not be Remote. If you 
just remember that the Component interface 
is where the business methods are, and the 
Home is where the, um, Home methods are, 
you should be fine. Just remember, Component 
=business = EJBObject (or EJBLocc?/Object, but 
we won’t go there until the next chapter). 


f^irpen your pencil 


T F A stateful session bean can be shared 
between multiple clients. 

T F An entity bean can be shared between 
multiple clients, as long as the entity 
being shared is the same. 

T F Stateless session beans are created 
when the client invokes create on the 
Home. 

T F Stateful session beans are created 
when the client invokes create on the 
Home. 

T F There must be one stateless session 

bean per client, for as long as the client 
holds a reference to an EJBObject. 

T F There must be one stateless session 

bean per client, for as long as the client 
is in the middle of a business method 
invocation on the bean. 

T F Each entity bean must have its 
EJBObject. 
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tWeiqrenP 

Dumb Questions 


How does this work? Is there 
one bean pool for all beans, or one 
bean pool for a particular type of 
bean? 

In reality, we don’t know what 
the container implementation is, but 
conceptually there’s one pool for 
every bean type. So, if you deploy 
an AdviceBean and a WeatherBean, 
and both are stateless session beans, 
they’ll each get their own pool. 

Does each stateless session 
bean have its own EJBObject? 

Sort of. A stateless session 
bean doesn’t need a bodyguard 
until he’s actually involved in a 
method invocation. So, the client 
gets a reference to an EJBObject, 
but the bean isn’t associated with 
that EJBObject until the client calls 
a business method. At that point, 
the bean slides out of the pool to 
service the method. So, the EJBObject 
the client has is for a kind of bean 
(AdviceBean, WeatherBean, etc.) but 
not a specific instance of a bean. 


Why don't stateful session 
beans have a pool? 

Have you already thought 
about this in the Brain Power on the 
previous page? Because if you haven’t, 
don’t read any further until you’ve 
come up with your own ideas. If you 


made it this far, we assume that you 
already know the answer and we’re 
just confirming it... 

A stateful bean, remember, holds client 
conversational state.That means the 
bean has to save client-specific state 
(in other words, it has to remember 
things about this client) across 
multiple method invocations from the 
client. 

Think of a shopping cart again — a 
stateful bean needs to remember 
what’s in the client’s cart each time the 
client calls addltemToCartO. A stateless 
bean, on the other hand, doesn’t have 
to remember anything on the client’s 
behalf, so to a client, one stateless 
bean (of a particular type) is as good 
as any other bean of that type. 

If the AdviceBean simply returns 
a piece of advice not connected 
in any way to anything it told the 
client before (or anything the client 
told it), then there’s no need for the 
AdviceBean to be stateful. In that case, 
each time a client calls getAdviceO 
on the Component interface (i.e.the 
EJBObject), any AdviceBean is just as 
capable of running the method as any 
other. 

On the other hand, if the AdviceBean 
were modified to return, say, random 
but non-repeating advice,then the 
AdviceBean would have to be stateful, 
so that it could keep track of previous 
advice and never repeat it. 




How long does a stateful bean 


keep client-specific state? 


Only for the life of the session. 

A session continues until the client 
tells the bean he’s done (by calling 
removeO on the bean’s Component 
interface), or the server crashes, or the 
bean times out (we’ll cover that in the 
Session lifecycle chapter). 


So stateful session beans 
aren’t scalable? 

No, they are Just not os scalable 
as stateless beans. 


How can a stateful bean be 
scalable if you always need one bean 
for every client? 

You do need a separate bean 
allocated for each client, but not every 
bean has to be actively consuming 
resources. If the stateful session bean 
client is taking a long time between 
method calls, the stateful bean can 
be temporarily taken down and put 
in a state called passivation.This state 
preserves the client-specific state, of 
course, but reduces the number of 
beans currently alive in the server.The 
bean comes out of passivation and 
back into active duty (activation) when 
the client calls a business method. 
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message-driven bean overview 


Architectural overview: 
Message-driven beans 

Message-driven beans don’t have a client view. That means they don’t 
have interfaces (Remote or local) that expose methods to the client. In 
other words, message-driven beans don’t have a Home or EJBObject. 
They don’t have a Home interface or a Component interface. 



2 - The sewide delivevs -the message -to the 

3- The £.oh*t3mC\r yts 3 message—dvivc^ bed)^ ou*t o-f fool- 

4 - The dohtamcv ddivcvs the message h> the bea^ (by tiic bca^s 

ohMcssagcO McssagcListc^cv miev-fade mctliodi). 
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architectural overview 



What goes where? 

Place the objects and classes in the appropriate spot on either 
the client, the server, or in both places (yes, you can reuse an 
object). Note: not all the pieces are here, so when you’re done, 
if you can think of other things that should go into the picture 
(classes or objects) draw them in! 


client 


server 



101101 
101101 
10101000010 
1010 10 0 
01010 1 
1010101 
10101010 
1001010101 


101101 
101101 
10101000010 
1010 10 0 
01010 1 
1010101 
10101010 
1001010101 


EJBObject interface 


client class 


101101 ^ 
101101 
10101000010 
1010 10 0 
01010 1 
1010101 
10101010 
1001010101 


bean class 


lonoi Ps 
101101 
10101000010 
1010 10 0 
01010 1 
1010101 
10101010 
1001010101 


101101 
101101 
10101000010 
1010 10 0 
01010 1 
1010101 
10101010 
1001010101 


home class 


home stub class 
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bean table 



Organize your beans 

Finish the table by putting in a checkmark (even better if you 
add notes) in the boxes corresponding to the labels that apply 
to that bean type. We’ve done one of the boxes for you. If you 
get stuck, go back through the previous two chapters. You might 
have to make your best guess on a few things. That’s OK — 
you’ll have it all worked out way before the end of the book. We 
believe in you. You can do it. [cue theme song from “Rocky”] 


Stateful Session Stateful Session Entity Beans Message-driven 
Beans Beans Beans 


Uses a pool 

Yes. S'mdc iKcy 
dor /七 keep ar»y 
dlich-t-s^cdi-fid ddid ； 
you ohC 

pev- eddK dlicht 




Multiple clients can have a reference 
to the same bean 





Guaranteed to survive a container 
crash 





Has a client view 





Allows asynchronous communication 





Represents a process 





Represents a “thing” in an underly¬ 
ing persistent store (like a database) 
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exercise solution 


architectural overview 



Sote 


se 

ons 


What goes where? 




101101 
101101 
10101000010 
1010 10 0 
01010 1 
1010101 
10101010 
1001010101 


EJBObject interface 




101101 
101101 
10101000010 
1010 10 0 
01010 1 
1010101 
10101010 
1001010101 


101101 
101101 
10101000010 
1010 10 0 
01010 1 
1010101 
10101010 
1001010101 



home stub class 


client class 



client 



101101 
101101 
10101000010 
1010 10 0 
01010 1 
1010101 
10101010 
1001010101 


bean class 


' bean 

loiioi 


10101000010 
1010 10 0 
01010 1 
1010101 
10101010 
1001010101 


EJBObject interface 


101101 

， Home ' 

101101 ^ 

101101 

10101000010 
1010 10 0 

object / 

10101000010 
1010 10 0 

01010 1 


01010 1 

1010101 


1010101 

10101010 


10101010 

1001010101 


1001010101 


home class 


home stub class 


server 



NOTE: you won’t find a finished solution for the Organize 
Your Beans table. We want YOU to fill this out. It’s yet 
another special Learning Opportunity for which you’ll 
always remember us with fondness. 
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EJB architecture 



You’re in luck. This chapter is 
all background knowledge, so 
there aren’t any objectives or 
exam questions. 

Appreciate the moment — 
Chapter 3 is just a page turn 
away... 
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Chapter 2 


3 the client View i 

T 去 

♦ Exposing Yourself 



You can’t keep your bean private. Clients need to see what you ve got. 
(Except for message-driven beans, which don’t have a client view). The Advice Bean 
exposed the getAdvice() method in its Component interface — the place where you declare 
business methods. But that’s not all the client sees. Remember, the Advice interface 
extended EJBObject, an interface with methods of its own. Methods the client can see. 
Methods the client can call. And it works the same way with the Home interface. In this 
chapter, we’ll learn what you really expose to the client, and how the client works, including 
both Remote and local interfaces. 


this is a new chapter 
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exam objectives 






Ct neoiijcf meod^: 


2.1 Identify correct and incorrect 

statements or examples about the 
client view of a session bean’s local 
and remote home interfaces, including 
the code used by the client to locate a 
session bean^ home interface. 


You have to know everything about the home interface. 
This particular objective doesn’t include the special 
characteristics of an entity bean home, but most of the 
details about the client’s view of a bean’s home are still 
covered in this objective (and this chapter). 

For example, you have to know exactly which methods 
are in javax.ejb.EJBHome (the Remote home interface), 
and which methods are in javax.ejb.EJBLocalHome 
(the local home interface). And it’s not enough to know 
what the methods are — you also have to know the 
circumstances under which they can be called. You have 
to know, for instance, that a Remote session bean client 
can remove a bean using the bean’s home, but a local 
client cannot. And you have to know that a local home 
has fewer methods than a Remote home, and what that 
means for the client. 

Finally, for Objective 2.1, you have to know the ins and 
outs of how a client does a JNDI lookup on a bean’s 
home interface. That includes the syntax of the client’s 
lookup code, the rules for performing the lookup, and 
how to use the home interface to get a reference to 
a bean’s component interface. You have to know, for 
example, the rules for narrowing a home stub, and, given 
a code snippet, you must be able to recognize whether 
the client is local or Remote. 


2.2 Identify correct and incorrect 

statements or examples about the 
client view of a session bean’s local 
and remote component interfaces. 


This objective is just like 2.1, except it’s about the 
component interface. But again, you must know all the 
methods of both javax.ejb.EJBObject and 
javax.ejb.EJBLocalObject, and how they’re used by the 
client, and you must be able to recognize the difference 
between a Remote and local client, just by looking at 
code. 
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the client view 


What the client really wawts 

The client has a goal. A vision. A quest. She wants to call a business method on the 
bean! Something exposed in the component interface. Never forget that ultimate 
goal; it is easy to get bogged down in all the details. But if you keep focused on the 
client’s driving need, you’ll have a much easier time remembering things like, say, 
the return type of a session bean’s home create () method. 



But I can't 
get a reference 
to the bean... I have to 
go through the bean's 
component interface— 
the EJB object. 


o 

o 




But how do I get a 
reference to the EJB object? 
I have to go through the bean's 
home. Yeah, that's right... I need 
to start by getting the stub to 
the bean's Home object. 
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the Home interface 


It all starts with the home interface 



The client wants the bean. Well, too bad. The 
client will never get the bean, because nobody 
talks to the bean (except the container). 
The best the client can hope for is a 
reference to the bean’s bodyguard — the 
component interface. And the client 
gets a reference to the bean’s component 
interface by calling a method on the 


bean’s home interface. 



How come you said,"And the client gets a reference to 
the bean’s component interface …〃 You can’t have a reference to 
an interface in Java — you can reference an object, but you can’t 
reference an interface.The reference variable can be declared 
as an interface type, but that’s not the same thing. 

A- 

Jr \ m Well, actually it is the same thing. In this book, and in the 
spec, and in the exam, everywhere you see the phrase,"reference 
to an interface’; do a mental search and replace to make it, 
"reference to an object that implements the interface.” 

It can feel a little strange, if you haven’t read documents that use 
this convention, but you better get used to it. But don't worry, by 
Chapter 4, you’ll wonder how anyone ever said it differently... 


You said the client’s ultimate goal is to call methods on 
the bean. (OK, the component interface, but you know what I 
mean.) But with entity beans, you can have business methods 
in the home, right? So with entity beans, isn't it true that 
sometimes the client's goal is JUST to use the home? 


^at^ie client KEALLY 
wants is a reference to ike 
bean. Butlke best ike client 
can do is get a reference 
to the bean’s component 
interface - ^lie EjB object^. 

But if slie wants an EjB 
object reference, ike client 
Kas to get a reference to the 
bean’s hone interface. 

So fiat's ^ivkeve it begins ... 
ihe client does a lookup on 
ike bean’s hone. 


n: Yes, you’re right.They’re called "home business methods” 
(as opposed to plain old "home methods” or plain old "business 
methods”）. But they’re a special case we’ll look at later in the 
book.There are other reasons, too, for why you might need only 
the home of an entity bean. For example, if you want to create a 
bunch of new customers in a database, but you don’t want to do 
any other operations on references to those entity customers. 


*We use the word “EJB object” to mean the 
bean’s component interface (the bodyguard), 
i.e. the thing receiving method calls meant 
for the bean, regardless of whether the client 
is local or remote. 
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the client view 


How a client uses a session bean: 
create, use, and remove 


① Create 

Client asks the home interface for a reference to 
the bean's component interface. 

(Which means the client calls a create() method 
on the home stub.) 



Hoic： scv^al 


《 interface 》 

EJBHome 

//methods 


《 interface 》 

AdviceHome 

create() 




② Use 

Client calls business methods declared in the 
component interface. 

(Which means the client calls methods on the EJB 
object stub.) 


③ Remove 

Client tells the bean that he’s done using it. 

(Which means the client calls remove() on the 
bean’s EJB object stub.) 


〈〈 interface 〉〉 

Remote 


〈〈 interface 〉〉 

EJBObject 

remove() 

//more methods 


tall- 


《 interface 》 

Advice 


getAdvice() 
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using JNDI to get the home 


Put first wc have to get a home interface reference 

Iw other words, we have to get the stub to the home 
object... the thing we use to call created so that we caw get 
what we really wawt^ the EJP object stub! 


When you (the client) want a reference to a home interface, you go through 
JNDI. The process is pretty straightforward: you give JNDI a logical name 
(the name the deployer told the server to use), and you get back something 
that implements the home interface. 


Context ic = new 工 nitialContext (); 




lookup scvvitc- 


Object o = ic • lookup (''Advisor"); 


// a few more steps... 





Whafs 

JNDI stands for Java Naming and 
Directory Interface, and it’s an API for 
accessing naming and directory services. 
Although JNDI is quite powerful, there 
are only a few pieces of it you need to 
know for EJB —— how clients find it, how 
clients use it, how beans use it, and how to 
put things into it. 

The JNDI API can work with many 
different services, as long as that 
service has a JNDI driver (called a 
Service Provider). It’s a lot like JDBC, 
where you (the developer) use the JDBC 
API to send SQL statements to a variety 
of different databases. The JNDI driver 
translates the method calls you make 
on the JNDI API into something the 
underlying naming/directory service 
understands. 


<9 


JKPI of 必 a 

工七上 茶产 d a 




〆 a # oW oV)〆 


a ONVl ^Oh*tcx*t C9v\ 
hold objects as well as 

匕 oh*tex*ts. 
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the client view 


Getting the home interface stub 


(?) Get an InitialContext 


Context ic = new 工 nitialContext(); 

The InitialContext (a subtype of Context) is your entry 
point into the JNDI tree. It’s simply the first context from 
which you start navigating. Kind of like your current 
working directory (the one you cd to). 

The InitialContext constructor figures out where you 
should start. (We’ll talk about that in a minute.) Both 
Context and InitialContext are part of the javax.naming 
package, part of J2EE, but also added to J2SE with 
version 1.4. 


A JNDI ''virtual 
directory tree" 


U 七、 say 从 a 七 

the 

f Jfov \)C 3 y\S- 


•tV^C on 
\\Crt … oul 


② Lookup the bean’s home using the 
InitialContext 





Shopper 


ItemDB 


Object o = ic • lookup (''Advisor"); 

The lookup method takes a String that must match the name 
assigned to this bean’s JNDI deployment. If the deployer 
assigned an additional context to the bean, by naming it 
(at deploy-time) “bat/Advisor”，then the lookup code would 
change to: 

ic • lookup (''bat/Advisor"); 


③ Assign the result of the lookup to the 
Home interface reference 


AdviceHome home = (AdviceHome) o; 



The return type of the context lookup method is Object, 
so you have to cast it back to the bean’s home interface 
type, before you can call AdviceHome methods. 




sV^o'aIcA 


^1 out Wat ’ 
ust a ^ 
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the Home interface 


How do I know what the 
developer named the bean? 

A- 

厂 Actually, it’s not up to the bean 
developer (the EJB role known as Bean 
Provider — the one who actually wrote 
the bean code), to give the bean 
its JNDI name. Remember,the Bean 
Provider might have written that bean 
as a reusable component for Beans 'FT 
Us and thus might have no idea where 
and how the bean will be used. 

It’s the deployer — the person who 
actually gets the bean running in the 
server as part of some application — 
who registers the bean under a 
logical name. But the bottom line is 
that there’s no standard or automatic 
mechanism for learning the names 
of registered beans. As a client, 
somebody, somehow, has to tell you 
that, say, the bean was registered as 
"Advisor': 

Notice that "Advisor’; while describing 
the service, is not a String that 
corresponds directly to the names of 
any of the other pieces of the bean. 
Remember, the component interface 
was Advice, the home interface was 
AdviceHome, and the bean itself is 
AdviceBean.The name "Advisor” was 
just something the deployer thought 
had a nice ring to it. 

Of course, in your company, you might 
(and probably will) have strict naming 
guidelines to follow for how beans are 
registered with JNDI at deployment 
time. 

(Unless it’s your own company, in 
which case you can do whatever you 
darn well please, including naming 
each bean after your favorite rock star 
or Matrix character.) 


^tJiereiareriP 

Dumb Questions 


I just thought of an even 
BIGGER problem... how the heck do I 
know where to find the server? And 
how do I specify it? I didn’t see any 
code for an IP address or TCP port 
number. 

A. 

Good catch. Yeah, that's all 
a bit of a mystery, isn't it? We have 
three answers for now: 

1) We’re cheating a little, because 
the code we’re using works only 
because we’re using the Reference 
Implementation, and even then... only 
because we’re running the server on 
the same physical machine as the 
client. So, we’re taking advantage 

of default settings that are in place, 
automatically, because we’re running 
the Reference Implementation. 

2) . We lied a little in point number 1, 
above, because this code could be 
correct if it were inside a bean. (We’ll 
get to that in the Bean Environment 
chapter.) 

3) In reality, a client does need to 
know how to find the JNDI service 
where a bean’s home is registered. 
There are several ways you can do 
this — you could pass information 
to the InitialContext constructor 
(a Properties object that contains 
everything the InitialContext needs 
to find the server and the starting 
context). Or, there are several 
places where JNDI properties can 
be placed on the client’s machine. 

In either case, the client MUST be 
given something — either info for 
the InitialContext constructor, or a 
properties file. It’s different for each 
vendor’s server, too, so you have to 
check your documentation in order 
to know what the client needs. 


O 



For the exam, you don’t need 
to know much about JNDI! 

For the client-related objectives 
(the ones from this chapter), 
all you need to know is the 
fundamental process for doing a 
JNDI lookup … that you need to 
start with an InitialContext and 
then call lookupf), which returns 
something of type Object 

You do NOT need to know how 
the client or server finds and 
gets a reference to the correct 
InitialContext, only that an 
InitialContext is needed. 

In the Bean Environment 
chapter, well add a tiny bit more 
JNDI info, for how the bean itself 
uses JNDI to look up things that 
have been specifically placed 
there for the bean. 

But that’s about it for your JNDI 
knowledge. You don’t have to 
know any details about the rest 
of the JNDI API other than the 
Context.lookupO method. 
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the client view 


Lefs take another look at the complete client code 


import javax.naming•* 
import java.rmi.*; 
import javax.rmi.*; 
import headfirst.*; 
import javax.ejb.*; 




public class AdviceClient { 

public static void main(String[] args) { 

new AdviceClient () . go (); 丄 ^ i + m*bo *tV>C 

} l^alCo^ - o- looW ? 

X JNPI 

public void go () { f or\ A^ VlSO，r 

try { \L 

Context ic = new InitialContext () ; is 

Object o = ic • lookup (''Advisor"); 


; ⑶ & 一 


AdviceHome home 
Advice advisor 


(AdviceHome) PortableRemoteObj ect.narrow(o, AdviceHome.class); 
home.create (); 


tr c ^ 5ci us wc 

Y waht - 匕， hCh 七 iht r 

System.out.println(advisor.getAdvice()); 

Tk fomt o( cvcvytK'mg/ To 6all a business 
method ov\ -the bean ^via -tKc s-tub) 


catch (RemoteException rex) 
rex.printStackTrace (); 
catch (CreateException cex) 
cex.printStackTrace(); 
catch (Exception ex) { 
ex.printStackTrace (); 


^JtwUd ⑽ W.. 


e^irpen your pencil 


Match the class name with 
the package it’s from.You can 
use the same package name 
more than once. 

If you’re not sure, make your 
best guess. 


Package Name 

javax.naming 

java.rmi 
javax.rmi 
headfirst 
javax.ejb 


Class Name 

InitialContext 

AdviceHome 
PortableRemoteObj ect 
RemoteException 
Advice 

CreateException 
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casting and narrowing 


Just whew you thought a simple cast would be enough. 

The return value of the Context.lookup () method is type Object. So we’re 
thinking a simple cast should be enough to force the object referenced by o 
back to the AdviceHome implementation that we know it really is: 

Context ic = new 工 nitialContext () ; , nO 匕 vhWt, 心七心 ’ 乇 . 

Object o = ic . lookup (''Advisor") ; l~W»s V^owC 

AdviceHome home = (AdviceHome) o; ^_\A/.rtV\ a Kewo * 

^ ,s ^ 


Put NO. You have to Harrow the object as well! 


Narrowing forces the object returned from the JNDI lookup to be absolutely, 
positively, something that implements the home interface. In other words, 
something you can cast to AdviceHome. 


Context ic = new 工 nitialContext(); 
Object o = ic . lookup (''Advisor")_£_ 

AdviceHome home = (AdviceHome) 


PortableRemoteObject.narrow(o, AdviceHome.class); 


OK, ril bite. Why cawj you just do a plain old cast? 

According to the spec, you — the client — must assume that the server is using RMI- 
IIOP rather than regular old RMI. Normal RMI uses JRMP as the wire protocol, 
which assumes that we’re always talking Java all the way down. If this were plain 
RMI, you’d always know that what you get out of the lookup is (polymorphically) 
something that IS-A home interface. In other words, an object whose class type 
implements the home interface for that bean. And for that scenario, a normal Java 
language cast would let you assign the object back to the home interface type, 
so that you can call the home methods! Otherwise, remember, you’d be stuck 
calling only methods of type Object (equals(), hashCode(), toString(), etc.) 
when what you really want to call is create。. 

But when the wire protocol is HOP, the rules change a little. The narrow() 
operation gives you something that is castable. 
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the client view 


PortablcRcmotcObjcct.warrowO 


The javax.rmi.PortableRemoteObject^ narrow() method 
runs code written by the server vendor. But all we care about 
is that it takes the object we got from JNDI and gives us back 
something that really does implement the home interface. 

In other words, it gives us back something we can then cast 
to the home interface type, and call create(). 


PortableRemoteObject.narrow(o, AdviceHome.class); 



yt -fv-ow okpi 


O 




J (— 八 

You don't need to know the detaUs of «OP ^ 

i works, unless you nten t ^ Not 

i But- you DO ne r ^ tShe 

: s 二 s 界 : z c0 : 二 ed 

\ Narrowing the Remote st bs^ ^ //Qp 
- And there are a couP^^ 

\ IS /s t^ youjO h eve to ^ 

: aware that HOP = e == a d „ b «J 

\ ::: Z k e7^ y; a ^%ZT w about 

\ HOP before the chapter soon . 


The Kome stub returned from 
a JKDI lookup mi^itnot 
implement ike home interface! 

You back an HOP 

stub iiiat isn’t castable to ihe 
home interface of your bean. 
And that means you couldn’t 
call create(). 

To get a stub that’s castable 
to the liome interface, you 
have to first narrowQ ike 
object you get from ike JKDI 
lookup on the bean hone- 

(But only wdien^ie hme 
interface is Remote.) 
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PortableRemoteObject. narrowQ 


With a Remote 
home stub from 
JNDI, an ordinary cast 
isn't good enough. You need 
something more exotic... 
you need to narrow it. 



Ttefe of narrowing as 
Exotic Casting 

Narrowing is not the same as casting, but you 
can think of it as a form of “exotic casting”. 

Casting is about polymorphism. With a cast, 
the object doesn’t change, but the way you 
refer to that object does. With narrowing, you 
might actually get a different object! 

Cast 

Animal ani = new Dog(); 

Dog fido = (Dog) ani; 



\Y\ 


r\<\ 

rit v. 


Cast*»w 

out 

»ts 


tall, 




Narrow 

narrow (o, AdviceHome.class); 



Object 


"Hie ha^ow mc-thod 


V 」 S) 义 f y fW 

⑽私 Bui ^a^dl CSSl 


AdviceHome 


l 11 ^ a stub 仏 ai 
lly P 炉伙七 

so you 
Qh thch casi i-fc. f 


you 
really 
■fehc ih 
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the client view 


Now that we (finally) have the home stub, 
let’s use it to get what we REALLY want... 


① Call create() on the home interface to 
get the EJB object stub 


Advice advisor = 



.create(); 


The create method returns a reference to the 
component interface, Advice. In other words, it returns 
a stub to the EJB object (which implements Advice, the 
Remote component interface for this bean.) You don’t 
need to cast and narrow the EJB object stub. 


② Call a business method on the 

component interface (EJB object stub) 

System.out.println (advisor.getAdvice()); 

Nothing special here. It’s just a plain old method call on the 
reference to the Advice interface. 

Well, not quite. Remember, every Remote method call 
declares a RemoteException! And that’s a checked 
exception, so you MUST handle or declare it. 

try { 

System.out.println(advisor.getAdvice()); 

} catch(RemoteException rex) { 

rex.printStackTrace (); 


Wait a minute... how 
come we didn’t have to 
cast and narrow the EJB 
object stub, but we had to 
for the home stub? 
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don't narrow the EJBObject 


fjiereiareJiP 

Dumb Questions 

OK, I know, I know, ■ don’t need to learn the 
details of HOP, but I still want to understand WHY they 
use it. 

A- 

OK, a little more. IIOP,the wire protocol for 
CORBA, can represent more information than plain RMI. 
For example, NOP can propagate both transaction and 
security information... important things that you can’t 
send with a non-NOP remote method call. 

So HOP lets a container at least have the potential for 
interoperating with other servers, including (possibly) 
one that isn’t Java-based. 

Remember, CORBA is a standard that (among other 
things) can give two objects, written in two different 
languages, a chance to invoke each other’s methods. 

This does not mean that your server is necessarily using 
NOP.The spec says that YOU 一 the developer — have to 
assume the server is using NOP, which means you have 
to be sure your beans are NOP-compliant (we’ll talk 
about MOP compliance a little later in this chapter). 

If my server doesn’t use MOP, do I still have to 
do the whole narrowing thing? 

A- 

Jr \ m Yes and no. Your code might work just fine with 
nothing more than a cast. But — and this is a really huge 
but — your client code won’t be vendor-independent! In 
other words, you won’t have a portable app if you don’t 
use narrow, because redeploying the bean on a server 
that does use HOP will break the clients. 


Is there any downside to using narrow? Espe¬ 
cially if the server is not using MOP? 


A ： 


No downside (well, whatever overhead there 
is wouldn’t be worth the portability tradeoff). If your 
server isn’t using MOP, narrow() is most likely a no-op (i.e. 
do-nothing) method.The spec says to always narrow, 
and it won’t hurt you if it isn’t needed. 


The declared return type of 
create() is Ae component 
MerCace, not Object. 

SoAe EjB object comes back 
from create() already knowing 
yA&t it is (an iinplemeiiMion 
of your component interface). 


public Advice create() 

V 

nc 代七，切? 七 
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the client view 


Writing the Remote home interface for a session bean 

Now that you’ve seen the lookup and create process from the client’s point of view, 
we’ll see what you have to do to write a home interface for your bean. For session 
beans, the process is very easy. In fact, for stateless session beans, it’s ludicrously 
easy~you just declare a single, no-arg create () method. 

package headfirst; 

import javax.ejb.*; 

import java.rmi.RemoteException; 

public interface AdviceHome extends EJBHome { 

public Advice create () throws CreateException, RemoteException; 


Rules for the home interface 

① Import javax.ejb.* and j a va. rm i. Re m ote Exce pt i o n. 

( 5 ) Extend EJBHome. 

③ Declare a create() method that returns the component interface and 
declares a CreateException and RemoteException 

For stateless session beans, there can be only one create。, and it must NOT 
have arguments. 

命 Stateful session beans can have multiple, overloaded create() methods, and 
do NOT need to have a no-arg create()_ 

^ All create() methods must declare a CreateException and RemoteException, 
but they can also declare other application (checked) exceptions. 

命 The name of create methods in stateful beans must begin with “create” 
(createAccount(), createBigDog(), createFashionAdvisor(), etc.). 

命 For stateful session beans, arguments must be RMI-IIOP compatible (you 
know, Serializable, primtive, Remote, or arrays or collections of any of those). 
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the Home interface 


Remote home interface examples for session beans 

The examples on this page are all legal examples of Remote home interfaces. 
You’ll see some that could be both stateless and stateful, and some that could be 
only stateful (because they have a create method with arguments). We’ve dropped 
the package and import statements to put more on the page. 


① 


public interface CartHome extends EJBHome { 

public Cart create(String storelD) throws CreateException, RemoteException; 
public Cart create () throws CreateException, RemoteException; 


② 


public interface MatcherHome extends EJBHome { 

public Matcher create(String customerlD) throws CreateException, RemoteException; 
public Matcher createNewCustomer(String name, String login) 

throws CreateException, RemoteException; 


③ 


public interface TicketsHome extends EJBHome { 

public Tickets create () throws CreateException, 


RemoteException; 


④ 


public interface ClubHome extends EJBHome { 

public Club createExisting(String clubID) throws CreateException, RemoteException; 
public Club createNewClub (String clubName) throws CreateException, RemoteException; 


There’s only one interface here that could be a stateless session bean’s 
home — number 3. Notice, too, that number 4 has two create methods that 
both have the same argument — a String — but the methods are named 
differently to reflect what that particular create method is for. 
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the client view 


I wonder what else 
I can do with the home 
interface. I know there's 
more than just the create 
method... what methods are 
in EJBHome? 




〈〈 interface 〉〉 

EJBHome 

// what methods 
//are in here? 


//client can call 
//these methods 




〈〈 interface 〉〉 

AdviceHome 

create() 





… 3 h 

methods 
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the EJBHome interface 



What YOU write: 


〈〈 interface 〉〉 

AdviceHome 


createf) 


Remember，the container 
implements your home 
interface and matching stub. 

The container must 
implement EVERYTHING from 
AdviceHome and EJBHome. 


What the CLIENT sees: 


«interface» 

AdviceHome 

createf) 

getEJBMetaDataf) 
getHomeHandlef) 
remove(Handle h) 
remove(Object key) 





AdviceHomelmpI 


AdviceHomelmpLstub 

create() 


create() 

getEJBMetaData() 


getEJBMetaData() 

getHomeHandle() 


getHomeHandle() 1 

remove(Handle h) 


remove(Handle h) 

remove(Object key) 


remove(Object key) 


-tv^c tlass atM 

Remote obje 乙七 



ih c 


of ih C 
c °k)^i M 


Note: these aren’t necessarily the real names — 
the server generates these classes, and it can 
name them whatever it wants to. 
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the client view 


If you’re a client, and you want to... 

(T) get reflection-like information about the bean. 

Unless you’re a tool vendor, you’ll probably never need to call this 
method. It returns the EJBMetaData interface — something you can 
use to get more specific class information about the bean. If you’ve 
got yourself an EJBMetaData reference (by calling getEJBMetaData), 
you can call getHomelnterfaceClass(), getPrimaryKeyClass(), 
isSession(), and more. 

serialize the home so that you can use the home 
again later, without having to go through JNDI. 

Imagine you’re a client, and you’ve been working with a home — 
making a bunch of beans, calling home methods on entity beans, 
whatever. And now you have to reboot your machine. Or move to 
another machine. But you want to continue working with this home. 

What do you do? 

You could go back through JNDI and do the whole lookup thing again. 

But if you ask the home for a handle, you’ll get back a Serializable 
thing you can save and use later to get the home stub back without 
going through JNDI (more on handles a little later). 

( 3 ) tell the home you’re done with a se^ion bean. 

When you’re done with a session bean, you can tell the home by calling 
remove() and passing the EJB object’s handle. Yes that’s right, the EJB 
object Just as the home object can give you a handle (so that you can 
get the home stub back, later, without going through JNDI), the EJB object 
can give you a handle to itself. (We’ll see more of that later in this chapter.) 
You can use this version of remove() for entity beans as well, but with 
entity beans, it’s usually easier to call the other remove(). 

( 4 ^ tell the home to remove an entity bean. 

Notice we didn’t say, “Tell the home you’re done with an entity bean.” That’s 
because calling remove on an entity bean is drastically different from call¬ 
ing remove on a session bean. We’ll get into the details in the entity bean 
chapters, but the short version is: when you remove an entity bean, you’re 
not just telling the container that you’re done with the bean, you’re telling it 
that everyone is done with the bean. Forever. Because calling remove() on 
an entity bean means, 'Delete this entity from the persistent store." (Which 
usually means, “Delete this row from the database.”) 

This version of remove takes a primary key, which session beans don’t have, 
so unlike the other remove(), this version can be used for entity beans only. 


Call this method: 


《 interface 〉〉 

EJBHome 

EJBMetaData getEJBMetaDataf) 

HomeHandle getHomeHandle() 
void remove(Handle h) 
void remove(Object key) 


《 interface 〉〉 

EJBHome 

EJBMetaData getEJBMetaDataf) 
HomeHandle getHomeHandlef) 

void remove(Handle h) 
void remove(Object key) 


《 interface 》 

EJBHome 

EJBMetaData getEJBMetaDataf) 
HomeHandle getHomeHandlef) 

void remove(Handle h) 

void remove(Object key) 


〈〈 interface 〉〉 

EJBHome 

EJBMetaData getEJBMetaData() 
HomeHandle getHomeHandle() 
void remove(Handle h) 

void remove(Object key) 
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the EJBHome interface 



Hey, did I just 


see something about 
primary key? In the home 


a 


interface for 


session 


a 


bean? 


That can t be 


ght 


ri 


/ I know, isnt that odd? \ 

J But look... there's only one 
home interface, EJBHome, 
regardless of the bean type! There's 
no separate EJBSessionHome 
or EJBEntityHome—ifs just 
EJBHome for everything! / 


Does this mean the client has to know that she’s using a session bean and 
not an entity bean? Isn’t that something the client shouldn’t have to know? 

A- 

r \ m Yes,the client does have to know that when she’s got the home interface for 
a session bean, he can’t call the remove(Object primaryKey) method. If she does, 
she’ll get an exception (javax.ejb.RemoveException). It does feel like more of an 
implementation detail than the client should have to know (i.e. that it’s a session vs. 
entity bean), but in reality, you can’t expect to write an EJB client without knowing 
whether you’re communicating with a session or entity bean. For one thing, the way 
the client interacts with an entity bean home is completely different from the way a 
client uses a session bean home. You’ll see dramatic differences when we get to the 
entity bean chapters. 


130 


Chapter 3 
















the client view 
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Roses are red, blue is the sky, 
y ou carYt get a bean from JNDI. 

,t，s on, y th ^ home a client will spy, 
when he does a lookup on JNDI. 


■ 


■ 


■ 


The methods of the bean are exposed to the client 
through the component interface. 

The client can’t directly get a reference to the 
bean; the client must go through the bean’s EJB 
object, which implements the component inter¬ 
face. 

The client gets a reference to the bean’s EJB 
object from the bean’s home. 

To get the bean’s home, the client does a lookup 
on JNDI, using the logical name under which the 
bean was deployed. 

To do a JNDI lookup, the client must first get an 
InitialContext, which is the entry point into the 
server’s JNDI “virtual directory tree”. 

For a Remote home interface, the stub returned 
from JNDI must be both cast and narrowed. 

Narrowing is the “exotic casting” needed for stub 
objects that come from a method that does not 
return the stub’s client interface. Since the JNDI 
lookup returns type Object, the object returned 
from the lookup must be narrowed to the bean’s 
home interface, and then cast to the bean’s home 
interface. 

Narrowing is required for NOP stubs (NOP is 
the wire protocol for CORBA), because what’s 
returned from the lookup might not be capable of 
implementing multiple interfaces, and thus would 
know only about the methods in type Object. 
Narrowing returns an object that implements the 
home interface. 

The home interface extends EJBHome, which has 
four additional methods the client can see: 
getEJBMetaData, getHomeHandle, 
remove(Handle h), remove(Object primaryKey). 
The remove(Object primaryKey) must not be 
called on a session bean. 
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the Home interface 



Based on the rules for session bean home interfaces, which 
statements are true about this interface: 


import javax.ejb.EJBHome; 
import java.rmi.RemoteException; 

public interface CartHome extends EJBHome { 

public Cart create () throws CreateException, RemoteException; 


CartHome must not be the home of a stateful session bean. 
^ The interface is missing an import statement. 

]The create method is missing an exception. 

]Cart must be the class type of the bean. 

]Cart must be the interface that extends EJBObject. 

]The object returned from create。must be narrowed. 

]The object returned from create() does not need a cast. 


You MUST be 
able to look at 
code and infer 
a lot about it- 


The exam expects you to look at 

client, interface, or bean code, and 
make inferences about things you 
don’t see. You MUST know all of 
the rules for home and component 
interfaces. And there’s more … 
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the client view 


Put enough about the home... let's talk about 
the EJP object. The compowewt interface. 

The thiwg you REAUY wawt. 

Remember, all that InitialContext-JNDI-lookup-cast-narrow-create business 
was just to get what you really wanted all along — something with the business 
methods. Something you can use to get the bean to do whatever it is that bean 
was created for. Number crunching, online shopping, advice. 

package headfirst; 

import javax.ejb.*; 

import java.rmi.RemoteException; 

public interface Advice extends EJBObject { 

public String getAdvice() throws RemoteException; 


Rules for the component interface 

① Import javax.ejb.* and j a va. rm i. Re m ote Exce pt i o n. 

( 5 ) Extend EJBObject. 

③ Declare one or more business methods, that throw a RemoteException. 

Arguments and return types must be RMI-IIOP compatible (Serializable, primi¬ 
tive, Remote, or arrays or collections of any of those). 

命 You can have overloaded methods. 

Each method must declare a RemoteException. 

You can declare your own application exceptions, but they must NOT be run¬ 
time exceptions (in other words, they must be compiler-checked exceptions — 
subclasses of Exception but not subclasses of RuntimeException). 
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the Component interface 


I wonder what else I 
can do with the component 
interface. I know there's 
more than just the business 
methods... what methods are 
in EJBObject? 
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the client view 


Imagine what cjsc you might wawt to do 
with your EJP object rcfcrcwcc... 

You’re a client. You have a reference to the AdviceBean’s component 
interface. You know you can call getAdvice(). But now that you’ve gone 
to all the trouble of getting the stub, are there other things you might 
want to do? 


I can think of some things... 
like, what if I have the bean, but I 
lost the reference to the home, and now 
I want to make more beans of that type? 
Surely the bean knows its own home, right? 
I cant believe they would have been 
stupid enough to make you go back 
through JNDI... 
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the EJBObject interface 


EJBObject (the 
bean's bodyguard 
for business 
methods) 



What YOU write: 


〈〈 interface 》 

Advice 



Remember，the container 
implements your component 
interface and matching stub. 

The container must implement 
EVERYTHING from Advice and 
EJBObject. 


You better 
know these 
other methods 
inside and out- 

The exam expects you to know all 
five of the methods in EJBObject 
You have to know that they re 
available to Remote clients, and 
exactly how they’re used! 


What the CLIENT sees: 


《 interface 》 

_ Advice 

getAdvice() 

getPrimaryKey() 

getEJBHome() 

getHandlef) 

remove() 

isldentical() 




Advicelmpl 


AdvicelmpLstub 

getAdvice() ' 


getAdvice() 丨 

getPrimaryKey() 


getPrimaryKey() 

getEJBHome() 


getEJBHome() 

getHandlef) 


getHandlef) 

remove() 


removef) 

isldentical() 


isldentical() 
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the client view 


If you’re a client, and you want to... 

get the primary key of an entity bean 

We won’t go into this now, since we have 10 million pages on entity beans 
coming up. Just know that this does not apply to session beans, which don’t 
have a unique identity exposed to the client. But if the client somehow gets 
a reference to an entity bean (maybe by searching on a customer’s name) 
and wants the actual primary key, this is the method to call. Try it on a 
session bean, and you’ll get a big fat RemoteException (or EJBException if 
the client is local). 

(2) get the bean’s home 

Imagine you’ve got a bean, but you don’t have the bean’s home. And now 
you want to make more beans of that type. What do you do? You could do a 
JNDI lookup and get the home in the usual way. But what if you don’t have 
enough information to do the JNDI lookup? You can ask the bean to give 
you a reference to its home. Even if you are capable of doing a JNDI lookup 
on the home, calling getEJBHome() on the bean is more efficient. 

(§) save a reference to the EJBObject 

You’re shopping online, carefully putting items in your cart, after hours of 
painstaking research and decision-making on whether your girlfriend will 
prefer you in cornflower blue, or the Martha Stewart seafoam green. But 
before you can finish, you have to switch to another machine. No problem. 
You can ask the bean for a handle to the EJB object. You can use the 
handle to get back to your original EJB object and keep shopping. 

( 4 ) tell the bean you’re done with it 

When you’re finished with the bean, it's good manners to tell it you’re done, 
so the container can free up any resources it might be keeping on your 
behalf. DANGER!! We’re talking only about session beans here. Although 
you can call remove() on an entity bean, remember, it has a very different 
meaning (we’ll see that in the entity bean chapters). 


(B) compare two EJB object references to see if they 
reference the same bean. 

You’ve got two references to session bean EJB objects. Now you want to 
know if they’re really references to the same bean. The isldentical() method 
takes an EJB object reference and compares it to the EJB object on which 
you invoked isldentical(), and returns true or false. 


call this method: 


《 interface 〉〉 

EJBObject 

Object getPrimaryKeyf) 

EJBHome getEJBHome() 
Handle getHandlef) 
void re move () 

boolean isIdenticalfObject 0) 


《 interface 〉〉 

EJBObject 

Object getPrimaryKeyf) 

EJBHome getEJBHomef) 

Handle getHandlef) 
void re move () 

boolean isIdenticalfObject 0) 


《 interface 〉〉 

EJBObject 

Object getPrimaryKey() 
EJBHome getEJBHome() 

Handle getHandlef) 

void re move () 

boolean isIdenticalfObject 0) 


《 interface 〉〉 

EJBObject 

Object getPrimaryKeyf) 
EJBHome getEJBHome() 
Handle getHandlef) 
void removef) 
boolean isIdenticalfObject 0) 


《 interface 〉〉 

EJBObject 

Object getPrimaryKey() 
EJBHome getEJBHome() 

Handle getHandlef) 
void remove() 

boolean isIdenticalfObject 0 ) 


you are here ► 137 












the getHandlef) method 


You’re shopping. It’s tough, 
because you can’t decide whether 
you’re a spring or a summer. 

You don’t want to be rushed, but 
you’ve already got a bunch of 
stuff in your cart when you realize 
you’re five minutes late for work. 

You’d love to continue with your 
shopping once you get to work. 

What do you do? If it were 
Amazon, your shopping cart 
would still be there when you 
log-in from the Web. But this is a 
proprietary Swing-based shopping 
client app you’re using. How can 
you get your EJB object stub from 
your home machine to your work 
machine? 

You could try serializing the stub. 
Yeah, that might work. Then 
again, it might not. The stub has 
a live network connection, and 
there’s certainly no guarantee you 
can get that same connection, 
to the same EJB object again. 

And since that EJB object is 
the component interface for 
your own personal, temporary, 
shopping cart bean, you need 
a way to get back to your exact 
same EJB object again from work. 


《 interface 〉〉 

EJBObject 

Object getPrimaryKeyf) 
EJBHome getEJBHome() 

Handle getHandlef) 

void removef) 

boolean isldentical (Object o) 


Online shopping should not be rushed 
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the client view 


Thankfully, wc'vc got handles 



^y>dle 

、 / 



A handle can rescue your shopping experience. Ask 
the bean (via the EJBObject interface) for a handle: 

Handle myHandle = myCart.getHandle(); 

serialize it, email it to yourself, then deserialize on your 
work machine and you’re back in business. 

The handle is a Serializable thing that knows how to 
get back to the stub. It has a single method: 


A handle is a Serializable 
object iliatl^nows how to get 
back to ihe original Remote 
EjB object. It’S not a Stub, 
but it can GET the Stub. 


public EJBObject getEJBObject() 

So when you call it, you have to cast and narrow the 
stub that comes back! Remember, you always have to 
cast and narrow a stub unless the method that returns 
it has the actual Remote interface as its declared return 
type. Since the handle’s method has no frickin’ clue 
what your component interface is (say, ShoppingCart), 
you’re faced with the same scenario you had with the 
home stub you got from the JNDI lookup () method. 
Cast and narrow. Cast and narrow. Cast and narrow. 


It Kas just one method, 
getEjBObject(), that returns 
type Object. 


So you have to narrow and 
cast ike stub you get back! 


In your client code, you’ll have something like: 

// your code to get the serialized handle you saved earlier 
Handle h = this.restoreTheHandle(); 


// now use it to get the EJBObject stub 
Object o = h.getEJBObject(); 

Shopping cart = (Shopping) 


PortableRemoteObject.narrow(o, Shopping.class); 
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EJB Handles 


Wait a minute... isn't a handle a big 
security problem? You already said I could 
serialize a handle and put it on another machine, so 
what's to stop me from giving the handle to someone 
else? Someone who didn’t have access to the stub in the 
first place? And another thing bugs me about handles— 

I hope you’re not telling me the server has to keep 
shopping carts around forever, just in case a 
client comes back using a handle! 

Goodbye scalability... 



Don’t worry! You can’t use a handle as a 
way to violate your bean’s security. 

Your security is on a method-by-method basis, so 
even if you give a handle to someone else, if that 
client doesn’t have authorization to call methods 
on the bean, the stub they get back from the 
handle will be useless. 

Just because you still have a handle, doesn’t 
mean the server still has your bean. 

If you’re shopping and you get a handle, and 
then the server detects that you haven’t been 
doing anything with your cart for a while, the 
server can temporarily save your bean (known as 
passivation) to conserve resources, but keep your 
cart around just in case you come back. But if you 
still don’t come back within some time period, 
the server will destroy your cart with no hope of 
resurrecting it. That bean is history. 


In that case, your cart won’t be there when you 
call getEJBObject() on the handle, and you’ll get 
a RemoteException. 
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the client view 



isldewtical? 

how to find out if two stubs 
refer to the same bean 


《 interface 〉〉 

EJBObject 



銥 ㈣ £ 
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Object getPrimaryKeyf) 
EJBHome getEJBHome() 

Handle getHandlef) 
void re move () 

boolean isldentical(Object o) 


If you’ve got two stubs, and you want to know if they refer 
to the same bean, you call isldentical on one reference, 
passing in the reference you want to compare it against. 
Just like the way you use the equals () method. 


The trick is, stateless session beans, stateful session beans, 
and entity beans each have different rules for what causes 
isldentical () to return true. 


Stat eless session beans 

True if both references came from the same home, even if 
the stubs are referring to two different Remote EJB objects! 

To the server, one stateless bean is as good as any other 
bean from the same home, because the client would never 
be able to tell the difference (since the bean can’t hold any 
client-specific state). 

Stateful session beans 

False no matter what, for any two unique stubs, 
even if from the same home. After all, my 
shopping cart isn’t the same as yours! 

Entity beans 

True if the stubs refer to two entities with the same primary key. 
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the isldenticalf) method 



Stateless 

beans 


These bc5hs 
a " idch-ti^/ 


釙 c 


isldentical() always returns true, 
even for different beans. 


The isIdenticaK) mediodis 
like calling a Remote e 驭 als() 
mefiiod... except you're not 
asking if two objects on your 
are meaningfully equivalent, 
you're asking if two Remote 
objects are meaningfully 
e 神 valent -- on ihe server! 



Stateful 

beans 


TVsc locals av-c 
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isldentical() always returns false 
for different beans, even if the 
beans are from the same home. 


142 Chapter 3 



Entity 

beans 
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isldentical() returns true for beans* 
that reference the same entity (in 
other words, the same primary key) 

*We use the term “bean” here a little loosely because, 
conceptually, the server uses only one bean to 
represent a particular entity. So there would be only 
one bean with a primary key of #42, but clients may 
have multiple EJB object references to it. 





the client view 


^Lerei^ireJiP 

Dumb Questions 


Why can't you just use the equalsO method 
instead of isldentical()? Isn’t that what equalsO is for? 


A ： 


Remember, we’re talking about Remote objects. 
The equalsO method compares two objects on the 
same HEAP, where isldentical() compares two Remote 
objects on the SERVER. 


I still don’t see why they couldn’t have just 
implemented the equalsO method on the stub to do 
the same thing. 

A- 

The equalsO method is not a remote method, 
for one thing. You can always call equalsO on a stub, 
because you can call it on any object on your heap. 

But it’s not part of the remote interface, so it can’t be 
a remote method (for example, it doesn’t declare a 
RemoteException, etc.) 

And remember, the equalsO method is used to see if 
two objects on the heap are meaningfully equivalent. 
The vendor can implement the equalsO method on 
the stub any way it likes, but that still doesn’t tell you 
anything about what’s going on back at the server 
end. Just because two stubs don’t pass the equalsO test, 
doesn’t mean the server doesn’t consider the two EJB 
objects to be identical (or referencing identical beans). 

Your server may be using RMI stubs, for example, that 
have no logic for how their comparisons relate to 
meaningful comparisons of two EJB objects on the 
server. RMI stubs know about Remote objects, but they 
don’t know what those Remote objects represent. 


How come there's a method in the EJBObject 
interface for getting the bean’s home? If you don’t 
HAVE the home, then how did you get the bean in the 
first place??? 

A. 

There are other ways to get a reference to an EJB 
object. It’s true that you can’t use JNDI to look up the 
EJB object; only the home is registered. 

BUT", there’s nothing to stop you from passing an EJB 
object reference as an argument or return value. You 
might have a business method in one bean, whose sole 
job is to hand you back a reference to an EJB object for a 
different bean. 

Now suppose you have this EJB object reference, to a 
bean whose home you never had, and now you want to 
make more of those beans for yourself. You can do that 
by asking for the bean’s home using getEJBHomeO. 

And even if you do have enough information to do a 
lookup in JNDI for that bean’s home, JNDI lookups are 
expensive. You’ll save some overhead if you just get the 
home reference from the bean directly. 

Why can't you serialize the stub? Why do we 
need handles? 

A- 

Jr \ m We didn't say the stub wasn’t Serializable. But 
even if you can serialize it, that doesn’t mean it’s got 
enough information to get you back to the same (or 
meaningfully identical) EJB object. When the stub comes 
over from the server, it’s already knowledgeable about 
how to contact a particular Remote object. When that 
stub is recreated, that exact Remote object might not 
even exist any longer. 


Then how would the handle be any better? 


A ： 


The handle has the'smarts’to communicate 


with the server and get back something that is just the 
same as the EJB object you had before. In other words, 
it might not be the same EJB object, but the client will 
never be able to tell the difference. 
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You expose your bean’s business methods in the 
component interface. 

Remote component interfaces must extend 
javax.ejb.EJBObject. 

The client gets a reference to the bean’s EJBObject 
by calling a method on the bean’s home interface. 

References to both stateless and stateful session 
beans are retrieved from the home’s create() 
methods. 

From the EJBObject interface, the client sees five 
additional methods: getEJBHome(), getHandle(), 
remove(), isldentical(), and getPrimaryKey(). 

Only entity bean clients are allowed to call 
getPrimaryKey() on the bean’s component 
interface. Session bean clients will get a 
RemoteException. 

The getEJBHome() method returns a reference to 
the bean’s home interface, so that the client doesn’t 
have to go through a JNDI lookup, if they want to 
make more beans of that type. 

The getHandle() method returns a Serializable 
object that can be used later to reestablish contact 
with the server, and get back the stub to the 
component interface that the client used to get the 
handle. 

The handle has one method, getEJBObject(), that 
returns the Remote stub as type EJBObject. That 
means the stub must be cast and narrowed, just as 
you must do with the home stub that you get from a 
JNDI lookup. 

The isldentical() method is kind of like doing an 
equals() method on the server. It returns true for 
two different stateless beans from the same home, 
false for two different stateful beans from the same 
home, and true for references to entities with the 
same primary key. 
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the client view 


A bean’s client interfaces can be local 

We’ve looked at only the Remote client interfaces for a bean so far, but as 
of EJB 2.0, session and entity beans can expose a local client view. In other 
words, client interfaces that do not extend java.rmi.Remote. 

What does this mean? That the home object and EJB object are not Remote 
objects! They’re running in the same JVM as the client and the bean. In the 
entity bean CMR chapter, we’ll look at why local interfaces were added to 
the spec. For now, think of them as a very special case. 


Remote client view 


Local client view 


〈〈 interface 〉〉 

Remote 


〈〈 interface 〉〉 

Remote 



_ 


〈〈 interface 〉〉 

EJBHome 


〈〈 interface 》 

EJBObject 

//methods 


//methods 





〈〈 interface 〉〉 

AdviceHome 


〈〈 interface 〉〉 

Advice 

createf) 


getAdvicef) 



TV Ual m-tc^adcs do NOT 

javav-w'».Rcwo-tc 


(ar.a ouv Mm 叫 

… Wt 70U r^ccd 

to a»st»^5uisK 
^ 70 UV Remote 


The Remote interfaces EJBHome and EJBObject have more methods 
than the local interfaces EJBLocalHome and EJBLocalObject. Flip 
back through this chapter and look at the methods for EJBHome 
and EJBObject, and try to work out which methods in those Remote 
interfaces might be inappropriate or not needed in the local interfaces. 


Think about the implications of having the interfaces local to the client... 
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Remote vs. local client view 


REMOTE client view 




LOCAL client view 


丁 he dieht still get -fco 
•the bcah directly, because 
七 he sewev still heeds a pla^e 
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bcah (so the server cav\ add 
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the client view 



Given that the client has a plain old everyday Java 
reference to the home and component interfaces 
(i.e. the home object and the EJB object), which 
of the Remote interface methods do you think are 
appropriate for the local client view? 

In other words, which methods of EJBHome are not in 
EJBLocalHome, and which methods of EJBObject are not in 
EJBLocalObject? Why? 


Of the four methods in 
EJBHome, EJBLocalHome 
has only one. Which one? 


«interface» 

EJBHome 


《 interface 》 

EJBLocalHome 

EJBMetaData getEJBMetaDataf) 



HomeHandle getHomeHandle() 


1 

void remove(Handle h) 



void remove(Object key) 




Of the five methods in EJBObject, 
EJBLocalObject has only four (and 
one of the four is slightly different). 
Which four? 


M «interface» 

f EJBObject 


《 interface 》 

EJBLocalObject 

Object getPrimaryKey() 



EJBHome getEJBHome() 


1 - 

Handle getHandlef) 


Z 

void remove() 



boolean isldentical(EJBObject o) 


午 - 
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local interfaces 


Which methods make sense for the local client interfaces? 

You already know that the local client interfaces are missing some of the methods 
from their Remote counterparts. Let’s figure out which ones are missing, and why. 

Vo we need handles with local interfaces? 

- ■ 一 ■ 

Remember why handles exist in EJB — to give you a Serializable object that you 
can use to re-establish a stub to the EJB object you’d been working with. The 
handle is just an abstraction of a remote connection. So... does this make sense 
on a local client? 


9o we need EJPMetaPata with local interfaces? 

— — ^ —一 _ 

Remember what EJBMetaData is used for — to get reflection-like info about a 
bean. If you call getEJBMetaData () on a bean’s Remote home, you get back 
an object that implements EJBMetaData. That interface (EJBMetaData) has 
methods that let you interrogate the bean and learn more about the classes that 
make up the component. Would a local client ever need EJBMetaData? 


Po we weed isIdenticalO with local interfaces? 

一 —-— -* 

Remember why isldentical() exists — to let you compare two home or 
component interface references to see if they refer to “meaningfully equivalent” 
beans on the server. Would you need to use isldentical() on a local client? (Big 
Hint: the server is free to implement .equals() any way it chooses...) 

\/o we need primary key information with local interfaces? 

Remember why primary keys exist — to uniquely identify entity beans. Would 
you ever need to identify an entity bean on a local client? 


Po we need remove methods with local interfaces? 

Remember what remove () is used for — to tell the container that you’re done 
with a bean, for Session beans, or to tell the container to permanently delete the 
entity, for entity beans. Would a local client need to call remove () on a bean? 
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the client view 


Whew you thiwk handle, thiwk Remote 

一 I - 一 ""~^ 

Local clients don't need handles! 

Local clients have no use for a handle, because handles are 
strictly for getting a savable (Serializable) object that knows how 
to reestablish communication with the Remote object. 



LOCAL client view 


f Hds a P bi h Q \j 

如 ^ n p 7 old 


y\o s*tulos, 

Y\0 lldhdles 


Who needs EJPMetaPata whew 
you Ve got reflcctiow? 

Local clients don't need EJ^MetaPata! 


With the Java reflection API, you can interrogate an object to get all 
sorts of information about its class. With Remote objects, you don’t have 
that option, because you can’t get a reference to the class of the Remote 
object. The only thing you can interrogate on a Remote client are the 
stub objects, but they can’t tell you anything about the real EJB object or 
Home object. 

So while a Remote home client has to use EJBMetaData (the interface 
returned from the EJBHome getEJBMetaData () method) to get info, a 
local client will simply use the Java reflection methods (getClass(), etc.). 
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local interfaces 



isIdenticalQ 




iub 



LOCAL client view 




代 w -奶 arc ^七 



Po you weed isldewticalO when there's cqualsO? 

Local clients still need isIdenticalO 

Remember for a Remote client, the only local comparison you do is on two stub objects, 
using equals(). This doesn’t work when you want to compare something back on the 
server, in this case the two EJB object references. That’s what isldentical() is for. But local 
clients have the real thing! They have the real reference to the EJB object, so they can use 
equals(), to see if two EJB object (local) references are meaningfully equivalent. But... 
that’s still not what you want. There is no guarantee in the spec, for the results you’ll get 
with .equals ()! So while it seems like you could just use .equals () rather than isldentical() 
with a local client, the spec does not guarantee that the results will be the same. Bottom 
line: if you want to know if two EJB object references are referencing the same session 
object, you have to use isldentical() even when the EJB object is local. 

REMOTE client view 
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the client view 


Why so mawy remove methods? 

For Remote clients, twoiw the home, plus owe iw the 
component interface 

Remember, Remote clients have three remove () methods available, two in the 
home, and one in the component interface. The remove () that comes from 
EJBObject is simple; if you call it, you’re saying you want to remove that very beanl In 
other words, the bean whose EJBObject you used to call remove (). And for session 
beans, remember, calling remove () simply tells the container that you’re done with 
the bean. It’s good manners, and it improves scalability since the server can stop 
keeping client-specific resources on your behalf, rather than waiting, say, for your 
shopping session to time out from inactivity. 

But things aren’t so simple when you call remove on a home. For one thing, you 
actually can y t remove a home! The server keeps the bean home alive whether you’re 
around or not, so there’s no significant client-specific resources. There’s no need to 
tell the server you’re done with the home, because the server would simply say, “So 
what?” 

Then what does it mean to call remove () on a home? 

It means you’re telling the home to remove one of the beans that came from that 
home. And that means you have to identify which bean you’re talking about! 


REMOTE client view 




y-CwOVC 3 s ? 


(㈣ 一 


WWCH 


《 interface 》 


«interface» 

EJBHome 


EJBObject 

EJBMetaData getEJBMetaDataf) 


Object getPrimaryKeyf) 

HomeHandle getHomeHandle() 


EJBHome getEJBHomef) 

void remove(Handle h) 


Handle getHandlef) 

void remove(Object key) 


void remove() 


\ 

boolean isldentical(Object o) 

\ 



J 1 y° u —cd ^oveO. 
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remove methods 


Why there’s not a no-arg remove 
method in the home... 





Which bean??? you’ve given out, 
like, a million beans so far, and I have 
no idea which one you want to nuke. 
Come on, work with me here, Homie. I 
need something that uniquely identifies 
the bean. Otherwise, I’ll just pick one at 
random and kill it. And we really don’t 
want that now, do we? 


④ 
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the client view 


How caw you use a remove that takes a 
handle when you don't have a handle? 

Local clients don't have handles, so local homes 
don't have a rcmovcO that takes a handle. 


If local home interfaces don’t have handles, then 
there’s no way you could have a remove method that 
takes a handle. Because in order to pass a handle to 
the home, that uniquely identifies the bean you’re 
trying to remove, you’d have to first get the bean’s 
handle. And since locally-exposed beans don’t have 
handles... you see the problem. 



What if you have a local home, but you have a 
Remote EJB object reference? Can’t you pass the Remote 
bean’s handle to the local home? 

A- 

NO!! Because you can’t mix local and Remote 
interfaces together. Only a local bean comes from a local 
home, and vice-versa. So it will NEVER be possible to have 
a Remote bean’s handle, to give to that same Remote 
bean’s home, unless that home is also Remote. 

We didn’t say that very well, did we... OK how about 
this — a Remote home will hand out only Remote references 
to the component (EJBObject) interface for that bean type, 
and a local home will only return local references to the 
component (EJBLocalObject) interface. 

Tell me again why you can’t remove the home. 

A- 

Jr \ m There’s never a reason to remove the home (in 
other words, to tell the container you're done with it), 
because the container must keep the home around with 
or without your interest. So if you were able to say remove 
to the home, the container would say,"Gee...don’t flatter 
yourself buddy. What I do here on the server is not ABOUT 
you. I could care less when you’re done with your home 
reference.” 


You don’t call remove on a 
Koine to remove the home. 

You call remove on a home 
to tell ihe home to remove 
a bean . 

A bean from that home type. 

That means you must 
im 冲 iely identify Ae bean 
you want removed, vAien 
you call a Koine remove 
method. For entity beans, 
use Ae priinaiy l^ey or a 
handle, and for session 
beans, use a handle. 

But handles only worl^ for 
Remote home clients... 
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comparing local vs. Remote 


Comparing Remote vs. Local interfaces 

The EJBObject and EJBHome interfaces have more methods than the 
EJBLocalObject and EJBLocalHome interfaces because there are methods 
that don’t make sense in a local context. 


REMOTE client view 


LOCAL client view 


《 interface 》 

EJBHome 


《 interface 》 

EJBLocalHome 

EJBMetaData getEJBMetaDataf) 


EJBMetaData/^Bt^JBMetaData() 

HomeHandle getHomeHandlef) 


HomeHandle ^(fomeHandlef) 

void remove(Handle h) 


void rem^^Handle h) 

void remove(Object key) 


void remove(Object key) 
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《 interface 》 

EJBObject 


«interface» 

EJBLocalObject 

Object getPrimaryKeyf) 


Object getPrimaryKeyf) 

EJBHome getEJBHome() 


EJBLocalHome getEJBLocalHome() 

Handle getHandlef) 


Handle^tHandle() 

void remove() 


void removef) 

boolean isldentical(EJBObject o) 


boolean isldentical(Object o) 


Ko V^a^ks m lo6al 咖士 
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the client view 


貧 ^irpen your pencil 

Based on what you now know about the difference between local 
and Remote client interfaces, decide if the following statements 
are true or false. You’ll have to make some inferences and smart 
guesses for some of them. 

Select all that are true: 


} The only way to remove a local session bean is through the component interface 

]Entity beans can be removed through a local home interface 

^ If you see an isldentical() call, this must be a local bean 

^ If you see a getHandle() call, this must be a Remote bean 

]If the client is catching a RemoteException on a home method, the bean’s home 
interface must extend EJBLocalHome 

^ If the client is not handling a RemoteException on a business method, the bean’s 
component interface must extend EJBObject. 

^ If you see a call to getEJBMetaData(), the bean’s component interface must extend 
EJBLocalObject. 

Q If you do a JNDI lookup on a local home, you must narrow the object returned from JNDI 
]There are three methods in the EJBLocalObject interface 

]There are two methods in the EJBLocalHome interface 
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local interfaces 


Writing the local client interfaces 

Now that we’ve covered what the client sees in a local interface, let’s look at 
your responsibility as a Bean Provider. In other words, what you have to do to 
write the local interfaces for your bean. 


Component interface: 

package headfirst; 
import javax.ejb.*; 

public interface AdviceLocal extends 
public String getAdvice(); ^_ _ 

} iKis v-c-tuvC-tv^c docs^i b> be RMl- ^^o-tcEx^cp-ti 0h // 
\\0? (al-tKougK i-t 

be, o( douv-sc, like 




㈣ 麟 


EJBLocalObject 


Home interface: 

package headfirst; 
import javax.ejb.*; 






public interface AdviceHomeLocal extends EJBLocalHome { 


public AdviceLocal create () throws CreateException 




Th，S mST bc ihc 


still 3 Cv*ca 七七 io 灼 

bu 七⑽ Rcmo-tcE^cptio^ 


- Rules for local interfaces - 

① Import javax.ejb.* (or use fully-qualified names). 

② Extend EJBLocalObject (for the component interface) or 
EJBLocalHome (for the home interface). 

(3) Declare one or more business methods in the component interface. 

④ All create methods in the local home must return the local component interface, 
and declare a CreateException. 

⑤ Any method you declare in the home or component interface can declare your 
own application exceptions, which must be compiler-checked exceptions (i.e. 
not subclasses of RuntimeException).. 

⑥ You must NOT declare a RemoteException for any methods 
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the client view 


You caw have both a Remote 
and local client view for a bean, 
but you probably won't. 

We mentioned earlier that local interfaces are 
a very special case for a client view. They were 
introduced with version 2.0 of the EJB spec (which 
this book is based on) and the original intent was 
to support container-managed relationships in 
entity beans. But enough customers and vendors 
asked for the ability to have non-Remote interfaces 
for beans, so the J2EE team decided to make it 
available for session beans as well as entity beans. 

But regardless of which you choose, it’s very 
unlikely you’ll have a design that requires both 
a local and Remote client view. If your bean is in 
a container-managed relationship with another 
entity bean (you’ll learn all about this in the entity 
chapters), you have no choice. The bean must 
expose itself locally. And in that case, it’s almost 
impossible to think of a reason to also have that 
same bean exposed to Remote clients for other 
purposes. 

Just know that it is legal to have both. 

But you can never ， ever, ever mix and match. 

A Remote home interface can give out only Remote 
component interface references (in other words, a 
stub to the Remote EJBObject). A local home can 
give out only local component interface references 
(in other words, a regular Java heap reference to 
the EJBLocalObject). 


You can’t mix local and 
Remote interfaces together 

for the sme bean, even 
iJiougk a given bean can 
e^ose bo&a Remote and 
local client view. 

But a Remote home will give 
out only Remote component 
interface references (stubs), 
and a loc^Ilioine will give 
out only local component 
interface references 
(regular Java references). 
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local clients 



Change the AdviceClient from a Remote client to a local client, 
using the local interfaces for AdviceLocal and AdviceHomeLocal. 
Do NOT turn the next page!! 


import 

import 

import 

import 

import 


javax.naming.*; 
java.rmi.*; 
javax.rmi.*; 
headfirst. *; 
javax.ejb•*; 


public class AdviceClient { 

public static void main(String[] args) { 

new AdviceClient () .go (); 


public void go() 
try { 

Context ic 
Object o = 


=new 工 nitialContext(); 
ic . lookup (''Advisor") ; 


AdviceHome home = (AdviceHome) PortableRemoteObj ect.narrow(o, AdviceHome.class); 


Advice advisor = home.create(); 

System.out.printIn(advisor.getAdvice()); 
} catch (Exception ex) { 

ex.printStackTrace (); 


What has to change? Write the changed line (or lines) below: 
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the client view 


Exceptions \v\ client interfaces: what the client might get 


A Remote interface must have RemoteException declared on every method. That means the 
client using a Remote interface must deal with RemoteException for every Remote method call. 
But local interfaces don’t have that restriction. The only methods in a local client interface that 
must declare exceptions are the create () and remove () methods (for session beans; entity beans 
also have a finder method that declares a FinderException). 

We have a whole chapter devoted to exceptions in EJB, so we won’t go into the details now, but 
the essence is this: if a bean (or the Container) generates a runtime exception, Remote clients see 
the exception as a checked RemoteException, but local clients see it as an unchecked EJBException. 

In addition to whatever other checked exceptions (called application exceptions in EJB) the 
interface methods declare, all Remote interface methods can throw a RemoteException and 
local client interface methods can always throw an EJBException. So Remote clients must wrap all 
calls to a home or component interface method in a try/catch, while local clients use a try/catch 
only if the interface method declares an application exception (which includes CreateException, 
RemoveException, FinderException, and any other exceptions the Bean Provider declares in the 
methods of the bean’s client interfaces). 

^ Indicates a compiler-checked exception (i.e. non-RuntimeException) 


REMOTE client view 


LOCAL client view 


ALL methods 



javax.ejb.RemoteException 


javax.ejb.EJBException 


CREATE methods 



javax.ejb.RemoteException 
javax.ejb.CreateException 



javax.ejb.EJBException 
javax.ejb.CreateException 


REMOVE methods 



javax.ejb.RemoteException 
javax.ejb.RemoveException 



javax.ejb.EJBException 
javax.ejb.RemoveException 
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Local client code 

Compare this to the code modifications you made on the previous sharpen. 

To help show that the calls to the home and component interface are no 
longer Remote, we’ve made the exception handling more fine-grained. Notice 
that we’re not catching a RemoteException. 


import j avax.naming.*; . , 

import headfirst. *; y/c 

import j avax . e jb . *; java v-w*> •imports 

public class AdviceLocalClient { 

public static void main(String[] args) 
new AdviceLocalClient() .go (); 

} 


public void go() { 

Object o = null 


try 


ao ONPI. do : 广 


Context ic = new 工 nitialContext (); 
o = ic . lookup ( 、 'AdvisorLocal 〃）； 




catch (NamingException nex) 
nex.printStackTrace (); 


AdviceHomeLocal home = (AdviceHomeLocal) o 
AdviceLocal advisor = null; 


try 


e w 。…“㈣ 忒 i t J w 


advisor = home.create(); 

catch (CreateException cex) 
cex.printStackTrace (); 


㈤ )以工二作 


OY\ 


System.out.printIn(advisor.getAdvice()) 


几 e busi hcss 
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the client view 


What has to change inside the beaw class? 

We’ve seen how the interfaces change, and how the client code has to 
change, when you go from a Remote to local client view. But what about the 
bean class itself? What do you think? Does the bean code need to change, 
if you’re going to deploy it with a local client view instead of a Remote client 
view? What if you plan to deploy it with both a local and Remote client view? 

For now, let’s assume that the only method that matters is the bean’s 
business method. Here’s how it looks in the original bean class: 

public String getAdvice() { 

System. out .print In (''in get advice ”）； 

int random = (int) (Math.random() * adviceStrings.length); 

return adviceStrings[random]; 

} 

Do you see anything in that method that looks specific to a Remote client 
view? Would you need to do anything different with a local client? 

No, don’t think so. 

Anything that works as a return type or argument for a Remote method is 
guaranteed to work for a local method as well, so we’re OK there. (Kind 
of a no-brainer when the return type is String, though.) OK, there is one 
exception —— remember, according to Bean law you must not return a bean’s 
Remote interface from a local interface method. 

So it looks like (at least with this bean) we should never have to know or 
care. We should be able to deploy the bean as written, and the bean should 
be kept unaware of whether its clients are Remote or local. 

Sounds good, doesn’t it? Simple, clean, object-oriented. 

But think about it some more. Imagine a bean with more complex logic. 

More business methods. Arguments to those methods. Arguments the 
method might even need to act on. 

Hmmmmm... can you think of anything that the bean might want to treat 
differently, if it knew the client were local instead of Remote? 


you are here ► 


161 




passing objects locally 


Wait a minute... Java 
passes objects locally by passing 
a copy of the object reference, not 
the object itself. But we know that 
Remote method arguments and return 
values are passed as a Serialized 
copy of the actual object... 



In ordinary local method calls, Java passes 
an object reference by value, as a copy of the 
reference variable. 

The object itself is never passed. 

But with Remote calls, the object itself is copied. 

With Remote calls, the called method is always 
working on a copy of the caller’s object. 

With local calls, the called method is always working 
with the caller’s original object — not a copy! 
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the client view 


Arguments to Remote vs. local methods 



REMOTE method call 
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Remote vs. local 


So, I'm still not clear if the 
bean MUST always know if the client 
is Remote or local. 

A- 

It r s not that the bean must, 
but rather that the bean might have 
to know. If it matters that the bean 
is working on a the caller’s object, 

(via a copy of the caller’s reference) 
as opposed to a copy of the caller’s 
object,your bean code might have 
to change. And that goes for return 
values too. If it matters that the calling 
method gets back a copy of a refer¬ 
ence vs. a copy of an object, the bean 
code might have to change. 


But I thought that choosing to 
deploy a bean with local vs. Remote 
client views was just a matter of 
switching a switch at deploy time. 

NO! NO! NO! Let's imagine that 
you did write two sets of interfaces, 
one for a local client view and one 
for a Remote client view. It is true 
that at deployment you could decide 
which of the two views you wanted to 
expose (or both). But that works only 
if the bean code doesn’t care where 
the client is. A bean method with no 
arguments or return values might be 
safe regardless of how the client is 
accessing it. 

One solution might be to write the 
bean code assuming the bean is 
always getting a copy, and then if the 
client is local, have the client make 
a copy (clone) of the object before 
passing it. Or, for return values,you 
might always have the bean make a 
copy before handing it back.That way. 


^Lerei^ireriP 

Dumb Questions 


the bean never has to worry that a 
local client might be modifying the 
bean’s object. 


Then it's just about 
arguments and return values? Is 
there any other reason you couldn’t 
deploy a bean and make the 
decision for Remote vs. local view at 
deploy time? 


A. 

There is another reason.The 
client code! Even if the bean doesn’t 
need to know how its client is 


accessing it, the client must know! A 
client written to access a bean locally 
wouldn’t work if the bean’s Remote 


client interfaces, and vice-versa. 


Why not? 


A ： 


The client must know in 


advance whether its accessing a 
bean’s Remote or local client view, 


because the interfaces themselves 
are different. Polymorphically, you 
can’t use the Remote and local 
views interchangeably, because the 
interfaces themselves are different. 


There’s no way the client can be 
kept blissfully ignorant*, because 
the behavior of the bean is different. 
Remember, a Remote client must 
handle RemoteExceptions, and 
narrow the Remote stub conning back 
from the lookup! And a Remote client 
is exposed to methods in the bean’s 
client interfaces — methods that 
don’t exist in the local interfaces. So a 
Remote client might, for example, try 
to call a getHandleO method on the 
local component interface, a method 
call that would never work. 


And a local client won’t have code 
to handle the RemoteExceptions or 
narrow the stubs. 

The bottom line is that deploying a 
bean with a Remote vs. local client 
view is a Big Deal. It's a commitment. 
The client has to know in advance. 

Can you get around this by 
declaring your RemoteExceptions 
on your local interface? And could 
you make an interface that is both 
Remote and local... by having 
your component interface (like 
Advice) extend both Remote and 
EJBLoca 丨 Object? What's the harm 
if the client simply always handles 
RemoteExceptions, and always does 
the narrowO? That way the client 
shouldn’t have to know. 

A- 

Jr \ m Still won’t work. For one thing, 
according to bean law, you’re not 
allowed to declare RemoteExceptions 
on local methods! So there’s no 
guarantee that your server would 
even /ef you deploy a bean with 
a local interface that declares 
RemoteExceptions. And there is no 
guarantee that the narrow() method 
would not cause problems. And then 
there are handles and all that other 
stuff... You need to just let this go. 
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BEfK^ Container 


Each of the code snippets on this page represents code from either 
an interface or a client. Your job is to play Container and decide 
whether each is legal according to both Java law and Bean 
law. In other words, even if the code compiles, it might still be 
WRONG to the Container, because it doesn’t comply with the 
rules of the EJB spec. Assume that everything you do NOT see is 
legal and correct. Figure out if the problem is a compiler error or a 
problem to the Container, and figure out how to fix it. 


A. In a local client: 

public void go () { 

Object o = null; 
try { 

Context ic = new InitialContext (); 
o = ic . lookup (''AdvisorLocal ”）； 

} catch (NamingException nex) { 
nex.printStackTrace (); 

} 

AdviceHomeLocal home = (AdviceHomeLocal) o; 
AdviceLocal advisor = null; 

// more stuff 


B. In a Remote client: 

public void go() { 

try { 

// look up the Advice bean, assign it 
// to advisor 
} catch (Exception ex) { 
ex.printStackTrace(); 

} 

System.out.println(advisor.getAdvice()) 


C. In a bean’s home interface 

package headfirst; 
import javax.ejb.*; 

public interface AdviceHome extends EJBHome { 

public Advice create () throws CreateException; 


D. In a bean’s component interface 

package headfirst; 
import javax.ejb.*; 

public interface AdviceLocal extends EJBLocalObject { 
public String getAdvice(); 
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local interfaces 
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■ 


■ 


■ 


■ 


■ 


■ 


■ 


■ 


■ 


■ 


■ 
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BULLET POINT 


You can expose your bean to local clients using a local client view. 

Local component interfaces must extend javax.ejb.EJBLocalObject. 
Local home interfaces must extend javax.ejb.EJBLocalHome. 

Methods in local client interfaces do NOT declare 
RemoteException. 

Some of the interface methods exposed to Remote clients are not 
exposed to local clients. 

Local clients cannot get handles, since handles are used to re¬ 
establish a connection to the Remote object. 

EJBMetaData is not used with local clients, since a local client can 
use reflection to interrogate the EJB object and Home object. 

Local home interfaces have only one remove() method—the one 
that takes a primary key. The remove() that takes a Handle doesn’t 
exist in the local home interface, since Handles aren’t used with a 
local client view. 

Because the only remove() in the local home interface requires a 
primary key argument, local session bean clients cannot remove 
a bean using the bean’s home; they can call remove() only on the 
bean’s component interface. 

EJBLocalHome has only one method: remove() that takes a 
primary key, because the getHomeHandle(), getEJBMetaData(), 
and remove(Handle) methods that are in EJBHome don’t apply to a 
local client view. 

The only method in EJBObject that is not also in EJBLocalObject is 
getHandle(). 

Arguments and return values are passed by value when using a 
local client view. In other words, they’re passed in the normal Java 
way (objects passed by a copy of the reference, primitives passed 
by a copy of the value). 

Local clients do not need to narrow the Home reference because 
it’s a normal Java reference, not a stub to a Remote object. 

Local clients do not need to catch RemoteExceptions, since local 
interface methods don’t declare RemoteExceptions. 


: di it! 


You have to 
recognize a 
local vs. Remote 
client view! 

Be prepared to look at bean code, 
client code, or interface code and 
know whether you f re looking at a 
Remote or local client view. 

And it might be subtle! 

For example, you might see the 
client make a business method call, 
and the argument to the method 
is a non-Serializable object Since 
you are to assume that the method 
is legal and correct, you KNOW 
that this must be a local interface 一 
you can’t pass a non-Serializable 
object as an argument or return 
value to or from a Remote method. 
Some of other gotchas to tell you 
whether the bean is local or Re¬ 
mote include: 

7. Client doesn^ narrow the Home. 

2. Client does^t handle any 
checked exceptions on a business 

method call. 

3. Client calls remove(Handle) on 
a bean’s home. 
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Solutions 
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BEfK^ Container 


A. In a local client 1 


B. In a Remote client 1 


public void go() 
Object o = null; 
try { 


Context ic = new InitialContext (); 
o = ic . lookup (''AdvisorLocal 〃）； 

} catch (NamingException nex) { 
nex.printStackTrace(); 

} 

AdviceHomeLocal home = (AdviceHomeLocal) o; 
AdviceLocal advisor = null; y? 

// more stuff 

A is “e. Because local, \i 
docs heed h> havvow -the 

Ohly a casi is 


public void go() { 

try { 

// look up the Advice bean, assign 
// it to advisor 


} catch (Exception ex) { 
ex.printStackTrace(); 

} 

System.out.printIn(advisor.getAdvice()); 



I 他 0 、 s _ U 


CT J or- ^o/nomc ^ a i\cmo^c 

tk mule is that you 峰 t deda 代 

oh each method ih the 

Qc 仏呷 i | 饮 docs^i cart, but Ccmbm 饮 will. 

/\七 sor^c pomt m the deploy p^odcss, this will -fail. 


C. In a bean’s home interface 

package headfirst; 
import javax.ejb.*; 


public interface AdviceHome extends EJBHome { 

public Advice create () throws CreateException; 


r^eeds 

(look at tKc irwpovts ； r> 。 javd.vWi. 决 ) 



D. In a bean’s component interface 

package headfirst; 
import javax.ejb.*; 

public interface AdviceLocal extends EJBLocalObject { 

public String getAdvice(); 加 eds ⑽ dedartd 
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Which capabilities are provided by both remote and local home interfaces for 
session beans? (Choose all that apply.) 

口 A. Creating a session object. 

Q B. Removing a session object. 

[I C. Getting a session object’s EJBMetaData. 

[I D. Getting a session object’s handle. 


z 


When locating a session bean’s remote home interface, which are steps that 
must occur to create a valid home interface reference? (Choose all that 
apply.) 


Q A. The session context must be narrowed, and the narrowed result cast. 

Q B. The result of the JNDI lookup must be narrowed, and the narrowed 
result cast. 

Q C. The initial context must be narrowed, and the narrowed result cast. 

Q D. The result of the JNDI lookup must be cast to an initial context, and 
then narrowed. 


Given a remote client 4 R’，that has valid references to session beans ‘A’ and ‘B’, 
and given that A is a local client to B, which statements are true? (Choose all 
that apply.) 

[1 A. R cannot pass his reference for A, to B. 

口 B. A cannot pass his reference for B ， to R. 

口 C. A cannot invoke methods on B. 

口 D. B cannot invoke methods on R. 
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When comparing two session objects, what is true? (Choose all that apply.) 

Q A. Using the isldentical() method, stateless session beans from the same 
home will always return true. 

Q B. Using the isldentical() method, stateful session beans from the same 
home will always return true. 

口 C. The isldentical() method can be used for only remote object 
references. 

口 D. Using the equals () method, stateless session beans from the same home 
are guaranteed to return true. 

口 E. Using the equals () method, stateful session beans from the same home 
are guaranteed to return true. 

Which statement(s) about session beans are true? (Choose all that apply.) 

口 A. The bean provider must write the method public void remove () in 
both stateless and stateful session classes. 

Q B. Local clients can remove session beans by calling a method on the 
bean’s home. 

口 C. The remove () method in the component interface can be used only by 
remote clients. 

口 D. To ask the EJBHome to remove a session bean, the client must provide 
the bean’s handle. 
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Which capabilities are provided by both remote and local home interfaces for 
session beans? (Choose all that apply.) be tV^rc 

A. Creating a session object. 

口 B. Removing a session object. 一 ov ^ 


口 C. Getting a session object’s EJBMetaData. - ⑽ t ih a lo^al horv»e 
Q D. Getting a session object’s handle. - y\o{, "m d loddl Komc 


z 


When locating a session bean’s remote home interface, which are steps that 
must occur to create a valid home interface reference? (Choose all that 
apply.) 


Q A. The session context must be narrowed, and the narrowed result cast. 

B. The result of the JNDI lookup must be narrowed, and the narrowed 
result cast. 

口 C. The initial context must be narrowed, and the narrowed result cast. 

Q D. The result of the JNDI lookup must be cast to an initial context, and 
then narrowed. 




3 


Given a remote client ‘R’，that has valid references to session beans ‘A’ and ‘B 
and given that A is a local client to B, which statements are true? (Choose all 
that apply.) 

Q A. R cannot pass his reference for A, to B. 

B. A cannot pass his reference for B ， to R. 
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□ C. 
[/ D. 


A cannot invoke methods on B. 
B cannot invoke methods on R. 
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When comparing two session objects, what is true? (Choose all that apply.) 




□ 


□ 


□ 


□ 


(s 〜沾 - 认 ) 


A. Using the isldentical() method, stateless session beans from the same 
home will always return true. 

B. Using the isldentical() method, stateful session beans from the same 
home will always return true. 

C. The isldentical() method can be used for only remote object 

references. . /n 

T i ok 

D. Using the equals () method, stateless session beans from the same home 
are guaranteed to return true. 

E. Using the equals () method, stateful session beans from the same home 
are guaranteed to return true. 


5 


Which statement(s) about session beans are true? (Choose all that apply.) 

Q A. The bean provider must write the method public void remove () in - 
both stateless and stateful session classes. 

Q B. Local clients can remove session beans by calling a method on the 
bean’s home. 


•心沙 R 一 ()， 孔 一 0 

一 lodal homes have only a 
v - cmovcO 七 ha 七 "takes a 
pvimavy key 


□ 


C. 


The remove () method in the component interface can be used only by 
remote clients. 


-⑽, ohly -fov \oCa\ 


D. To ask the EJBHome to remove a session bean, the client must provide 
the bean’s handle. 

一 k ho 七仏丄 EJBU 乙 altw 
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♦ Being a Session Bean 


I hate it when I get 
container callbacks. I just know 
ifs gonna be an ejbRemove(), but I 
was only just created... I wish I was 
stateless. They wont even let 
‘ me go in the pool... 




Session beans are created and removed, if you re lucky, you're a 
stateless bean. Because the life of a stateful bean is tied to the whims of a heartless 
client. Stateful beans are created at the client’s insistence, and exist only to serve that 
one client. As a stateful bean, the best you can hope for is that the client crashes or 
forgets to call remove(); it might take the Container a while to figure out you’ve become 
useless. But ahhhh, the life of a stateless bean is fabulous! Pools, those little umbrella 
drinks, and no boredom since you get to meet so many different clients. Of course, even 
a stateless bean dies with an unchecked exception... 


this is a new chapter 
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Sc^iOK 



3-1 Identify correct and incorrect statements or 
examples about session beans, including 
conversational state, the SessionBean 
interface, and create methods. 


3.2 Identify the use of, and the behavior of, the 
ejbPassivate method in a session bean, 
including the responsibilities of both the 
container and the bean provider. 


3.3 Identify the interface and method for 

each of the following: retrieve the session 
bean’s remote home interface, retrieve the 
session bean’s local component interface, 
determine if the session bean’s caller has 
a particular role, allow the instance to mark 
the current transaction as a rollback, retrieve 
the UserTransaction interface, prepare the 
instance for reuse following passivation, 
release resources prior to removal, 
identify the invoker of the bean instance’s 
component interface, be notified that a new 
transaction has begun, be notified that the 
current transaction has completed. 
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This objective can hit you on anything related to 
session beans, so you pretty much have to know it 
all, including the details of both stateless and stateful 
bean lifecycles, the container callback methods 
of SessionBean, what you must write in a bean 
class, and what a bean can get from its EJBContext. 
Anything covered by the other session bean objectives 
is fair game. 

First, you have to know that passivation is for only 
stateful session beans. Stateless beans go back to 
the bean pool without going through passivation. So, 
ejbPassivate() will never be called on a stateless 
bean. You have to know that your responsibility in 
ejbPassivate() is to make sure that when the method 
ends, your bean is ready for passivation, and that 
passivation may or may not involve serialization. You 
must know the state that your instance variables must 
be in at the time ejbPassivate() ends. And even though 
this objective doesn’t mention ejbActivate(), you have 
to understand how ejbActivate() works as well. 

You must be able to look at a description of a desired 
behavior, like, figure out the security principal of the 
client, and know which method you can call, and on 
which interface, to get that behavior (in this case, 
getCallerPrincipal() called on the SessionContext 
interface). 

To answer these questions, you have to know every 
method in the three key interfaces: SessionBean (the 
interface your bean implements), SessionContext 
(the interface your bean has a reference to), and 
SessionSynchronization (an optional interface that a 
stateful bean can implement). 

In this chapter, we’ll cover everything about session 
bean interfaces except SessionSynchronization, 
which is covered in the transactions chapter. 
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3.4 Match correct descriptions about purpose 
and function with which session bean 
type they apply to: stateless, stateful, or 
both. 


3.5 Given a list of responsibilities related to 
session beans, indentify those which are 
the responsibility of the session bean 
provider, and those which are the 
responsibility of the EJB container 
provider. 


3.6 Given a list of requirements, identify 

those which are the requirements for a 
session bean class, remote component 
interface, remote home interface, create 
methods, business methods, local 
component interface, remote component 
interface. 


You have to know the differences between stateless 
and stateful beans including when you’d choose one 
over the other. You must know the bean rules including: 
there can be only one create method in a state/ess bean, 
and it must have no arguments; only stated/ beans can 
implement SessionSynchronization, both stateless and 
stateful beans will not survive a container crash, state¬ 
less beans will never be passivated, state/ess bean 
creation and removal is not tied to the client. 

You have to know what is and isn’t guaranteed in the 
spec. For example, the container won’t allow concurrent 
access to a single session bean (if client A is using the 
bean, client B will get an exception if it calls a method 
on that bean). And the container isn’t required to allow 
a bean in one EAR file to be a local client to a bean in 
a different EAR. And you have to know exactly which 
classes and methods are implemented by you (the bean, 
the ejbRemove() and ejbCreate() methods, etc.), and 
which are implemented by the container (the handles, 
the home and component objects, the stubs (for Remote 
client interfaces), the getEJBObject() method, etc.). Most 
of what’s in this objective overlaps with 3.1,3.2, and 3.6. 

This is about knowing bean law — the rules you have to 
follow, according to the spec, even in the cases where 
compiler won’t care if you don’t. For example, you must 
have a matching ejbCreate() method for each create 
method in the home, but the compiler won’t stop you if 
you leave it out. And you must know that local interface 
methods must not declare a RemoteException, but 
Remote interface methods must. And you must know 
that object type arguments to a Remote interface 
method are sent as serialized copies of the object, while 
arguments to local interfaces are sent as copies of the 
reference. 
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Exploring the session bean lifecycle 


Imagine you’re a session bean. What matters to you? What are the key moments 
in your life? What do you need to know about the client? What do you need to 
know about the Container? What do you need to get from the Container? 

Now imagine you’re the client. What’s your motivation? What do you need to 
know about how the Container works? And what if you’re the Container? What 
do you have to do to manage a bean’s life, and when do you have to do it? 

If you’re the Bean Provider, what do you have to know about the bean’s lifecycle 
in order to write code that works? What if you want that code to be efficient} 

In this chapter, we look at the entire world of a session bean, and we do it from 
different points of view. We take an OO approach to this chapter, iterating 
through deeper levels of detail. So don’t panic if the first several pages feel 
a little too high-level, or leave you with questions. You’ll be down in the dirt 
before the chapter’s done. 

Before we start, let’s introduce the players: 



Container 



Goal ： understand the 
true meaning of its life. 
Where it came from, 
what its purpose \s t 
how will it all end... 


Peaw 



Goal: write deployable, 
well-behaved beans. 


god. Manage the life 
and death of beans, 


Goal: be the bean 


intercepting all of the 
beans method calls. 



Goal: call business 
methods on a bean 


Know the bean API well- 
enough to put the right 
code in the right place. 
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I create, use, and remove 
beans by calling methods on the 
home and component interface stubs. 
Someday, I will kill the Bean Provider 
with my bare hands, for never giving 
me the right stubs. 


Client 




I’m an object, and I run 
business methods, but I’m also 
a bean. As a bean, I pay attention to key 
milestones in my life like construction (boring), bean 
creation (very important), passivation (going to 
sleep), activation (waking up), and removal (death, 
not good if you're me). The container tells me 
everytime one of these special moments occurs. 

Most happen just once (construction, creation, 
removal), but activation, passivation, and 
business methods can happen over 
and over again. 


o 

o 


C3 

菸 ean 


I write the bean code. Besides the 
business methods, I have to implement 
the container callbacks (the ones the 
container calls when something happens in the 
bean's life). I also have to write the ejbCreate() 
methods to match the home create() methods. 
And I’m underpaid and they still haven't 
given me one of those Aeron™ chairs... 


Peaw Provider 




I construct the bean, I 
give the bean its beanness 
(special bean capabilities), and I call create 
on the bean, passing in client arguments if 
it’s a stateful bean. I decide if and when the 
bean should sleep and wake up, and I’m the 
only one that can kill (remove) a bean. I 
decide how and if a business method is 
called on a bean, factoring in things 
like security and transactions. 

To a bean, I’m a god. 


Container 
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You remember how it all works, right? 

Getting md using a stateful session bean 

This picture shows what happens after the client does a lookup 
in JNDI and gets the home stub. In other words, it shows the 
client getting and then using a bean. This picture is still too 
high-level, though, so we’ll go a lot deeper later in this chapter. 
For example, we’ll cover what really happens between step two 
(home object gets the client’s create () call) and step four (home 
makes the bean). The exam expects you to know just exactly 
what 5 s involved in “makes the bean”. ■ 


a bea^ 






Client calls create() on the home stub. 

Home object gets the create() call 

Home/container makes the EJBObject (component interface) for the bean 
Home/container makes the bean 

Home returns the EJBObject (component interface) stub to the client 
Client calls a business method on the component interface stub (getAdvice()) 
EJBObject gets the getAdvice() call 
Container steps in, and getAdvice() is called on the bean 
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Stateful Session Bean 


CREATION 




USE 

(business method call) 




get/\dvice() 


EJB 

bject 


7 get/\dvice() 
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session beans 


There's obviously wore to the beaw's lifecycle 
thaw just crcatiow a^id business methods... 

What about when a client wants to remove a bean? What about activation 
and passivation of stateful session beans? And what really does happen 
when a bean is created? What makes bean creation different from plain 
old object construction ? 

In this chapter, we’ll look at all the stages of a session bean’s life, for 
both stateful and stateless session beans. 


The bean lifecycle (special moments in a bean’s life) 

Stateful session beans 

■ Bean creation (when the client wants a bean) 

■ Bean use (when the client calls a business method) 

■ Bean passivation (the bean is put to sleep to conserve 
resources) 

■ Bean activation (the bean wakes up to service a business 
method from the client) 

■ Bean removal (when the client is finished with the bean, or 
the bean times out) 


Stateless session beans 

■ Bean creation (when the container wants to make a bean) 

■ Bean use (when the client calls a business method) 

■ Bean removal (when the container decides there are too 
many beans in the pool) 
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Container Callbacks, 
for the special moments m a beanls life... 



As a Bean Provider，YOU must implement 
container callbacks in your bean class! 


When a bean has a special moment, it doesn’t know until the 
Container calls one of the bean’s container callback methods. 
These are special methods the Container knows about, 
that you (the Bean Provider) must implement in your 
bean class. You can think of the container callbacks as 
being kind of like event handlers. 

Container callbacks come from two places: your bean’s 
home interface, and the SessionBean interface your 
session bean class must implement. 

For a session bean, the home-related container callbacks 
are matching creation methods (ejbCreate()) for each 
create() method declared in the bean’s home interface. 

The SessionBean interface declares four container 
callback methods for giving the bean its bean context, 
activating it, passivating it, and removing it. We’ll look at 
the actual methods on the next page. 





container callbacks 


Ccmtai 邮 r Callbacks come from TWO places: 


① 

Your home interface 


② 

SessionBean interface 

(javax.ejb.SessionBean) 


《 interface 〉〉 

AdviceHome 


create(String dientName) 





AdviceBean 


setSessionContext( SessionContext sc) 
ejbActivate() 
ejbPassivate() 
ejbRemove() 


ejbCreate( String dientName ) ① 






getAdvice() 


«interface» 



SessionBean 

setSessionContext(SessionContext sc) 

ej'bActivatef) 

ejbPassivate() 

ejbRemove() 


^ “ays 

七 1 ^ Fou K dMadk 

methods ih you^r scssioh bcah dhss 


For any session bean, you will always always always have at least five container 
callbacks — four from the SessionBean interface implementations, and at least 
one ejbCreate() to match the create () method declared in the home interface. 

For stateless session beans, there will be exactly five container callbacks, 
since stateless session beans can have only one create () method. And since 
the stateless bean’s create () is always a no-arg, you know that the bean’s 
ejbCreate() will always be a no-arg. 

For stateful beans, remember, there must be at least one create (), but there can 
be more, including both overloaded create () methods and create<something> 
methods. For example, a stateful bean home might have three create methods: 
create (), create (String s), createBigCustomer (String s). That would mean 
the bean would have three container callbacks from the home: ejbCreate(), 
ejbCreate (String s), ejbCreateBigCustomer(String s). 
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ImplemeHting the container callbacks 

This AdviceBean code is completely legal. It compiles and runs. Right now, we don’t 
need anything in the callback methods, because the bean’s business logic doesn’t 
depend on anything else that happens at other times in the bean’s life. You’ll notice 
that we are saving the SessionContext parameter we get from the setSessionContext() 
container callback, but we aren’t using it in this code. Later in this chapter, you’ll 
learn why you might want to assign the context to an instance variable, and the 
circumstances under which you would put code in each of these callback methods. 


package headfirst; 
import javax.ejb.*; 




y oVA MUST w—at 


public class AdviceBean implements SessionBean { 


private SessionContext context; 
private String name; 


ms-tahde vav-iablc -to Kold tiic doh-text wc 
gei a dohta'mcv- dallbadk method. 


public void e jbActivate () { 


public void ejbPassivate () 


public void e jbRemove () 


public void setSessionContext(SessionContext ctx) { 

context = ctx; 





public void ejbCreate (String clientName) 

name = clientName; 

} busih 

/ ih 

public String getAdvice() 

return ''Advice for+ name + '' : there is no spoon. 




、d /:上二 ㈣ 
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When are container callbacks invoked? 

For stateful session beans, when the bean transitions 
from one state to another. 


M _ bean throws system exception 

does not exist (unchecked, uncaught) 



① does not exist Before a bean is a bean (or even an object) it does not exist. The spec makes a big point of 

this, just in case there’s any confusion about something existing before it exists. So the state 
of non-existence is indeed a state that a bean can be in, even though it does not yet exist. 
When a session bean moves out of this state, the bean’s constructor runs, then setSession- 
Context(), and finally the ejbCreate() method. This is also the state a bean returns to after 
any one of these things occurs: bean times out, bean throws a system exception, ora client 
calls remove(). The bean will get an ejbRemove() call if the client calls remove() or times out 
while in the method ready (active) state. 


(2) method ready A bean in the method ready state is either executing a client’s method, or waiting for the client 

to make another business method call. A stateful bean might or might not be in an active 
transaction while in this state (depends on the deployment transaction settings and the caller's 
transaction status), but if the bean is in a transaction, the bean cannot be passivated. 

( 3 ) passivated A passivated bean is temporarily saved in some kind of secondary storage, to conserve 

resources between client calls. Passivation might be serialization, although the Container 
can use anything it wants as long as it behaves like serialization (with one small exception 
we’ll see later in this chapter). Although a passivated bean is no longer an active object on 
the heap, the Container will reactivate the bean (calling ejbActivate()) when the client calls a 
business method. If a passivated bean times out, the bean will simply die, without first being 
reactivated. 
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We have to look at the transitions 

Now that you’ve seen the overall state diagram, we have to 
drill down and find out what really happens (and why) when 
a stateful session bean transitions from one state to another. 


Moving from does not exist 
to method ready 


constructor 
setSessionContext() 
ejbCreate() 


does not 


exist 


bean throws system exception 
(unchecked, uncaught) 



Moving from method ready 
to passivated and vice-versa 

ejbPassivateO 

ejbActivate() 


does n 


constructor 

setSessionContextQ 
ejbCreate() 


bean throws system exception 
(unchecked, uncaught) 



method ready 



ejbRemove() 
or timeout 


ejbPassivateO 



ejbActivate() 


Moving from passivated or 
method ready to does not exist 


timeout, system exception 
or 

ejbRemoveO 


M _ bean throws system exception 

does not exist (unchecked, uncaught) 
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session beans 



If it’s so common to leave the methods empty, why don’t 
they have adapter classes like they have for event handlers — that 
implement all the methods from the interface? Is there any reason 
why your bean class can’t extend a class that implements the 
SessionBean interface? 

A. 

Jr \ m The API doesn’t have adapter classes for SessionBean 
implementations (i.e.a class that implements all of the methods). But 
there’s no reason you can’t make one yourself. Keep in mind, though, 
that with real-world beans you probably will have code in one or more 
of the methods. And you might even be working with a bean-aware IDE 
that puts the methods in for you anyway. 

Still, it might be handy to make yourself a generic bean that you 
typically extend from, that has all of the methods from SessionBean. 

With stateless beans, especially, you have to implement ejbActivateO and 
ejbPassivateO, even though they’ll never be called! (Stateless beans are 
never passivated; you’ll see more on that later in the chapter.) 

I just remembered that I read somewhere that enterprise beans 
don’t support inheritance! What’s that about? 

A. 

Ah... a common misconception. Well, sort of. EJB supports regular 
Java class inheritance, but has no concept of bean inheritance. And now 
you’re asking,"What the heck is the difference?” You already know what 
class inheritance is, it’s the thing you do in Java when one class extends 
another. And you can do that with a bean, just like any other class. 

But bean inheritance (if it were supported) would mean that a bean 
class could extend another bean class and inherit not just the class' 
inheritable members, but also its beonness. What kind of beanness 
might be inheritable? (Just in case they do decide to support this in 
the future, which is a possibility. Regular old non-enterprise beans do 
support bean inheritance.) 

One idea might be to have your bean subclass inherit some of the 
deployment descriptor settings of its superclass, and then override the 
ones it wants to change with a much smaller, incomplete deployment 
descriptor. That might be cool; we’re not sure. But right now, it’s just our 
little fantasy. 

In the meantime, go ahead and let your bean extend another class, if it 
makes sense for your 00 design. 


e^irpen your pencil 


For the exam, you have to know exactly 
which methods are in the SessionBean 
interface, so now is a good time to start 
memorizing them. See if you can remember 
the name of the method that matches the 
behavior described. We’ve included some 
pretty big hints here because it’s your first 
time, but the mock exam questions will be 
much less obvious... 


1. This method is called when the client tells 
the Container that he’s done using a stateful 
session bean. The bean is NOT happy: 


2. This method is called when the bean 
is put to sleep to temporarily conserve 
resources: 


3. This method is called when the previously- 
sleeping bean is called back to active duty 
to service a business method: 


4. This method is called near the beginning 
of the bean’s life, when the Container hands 
the bean a reference to the bean’s special 
link to the Container: 
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harpen your pencil 


Fill in the missing methods. Don’t worry if you don’t get the 
name exactly right; just try to work out what happens at each 
of the transitions in the stateful session bean state diagram. 


does not exist 


▲ 


bean throws system exception 
(unchecked, uncaught) 



method ready 


method calls 




1 






J 


or timeout 







You have to 
know this 
lifecycle! 

If you take the exam, you’ll thank 
us for beating it to death because 
you really must know it bdckwsr s 

and forward. 

But even as a bean developer, this 
is so fundamental to writing your 
bean code that you DO want to 

have this memorized. This isn’t 
like one of those API memorization 
questions where you think, ::lsnt 
that what the docs are for? 

Even if you have an IDE that puts 
the container callbacks into your 
code for you, you still have to 
know what they mean and what 
you should or should not do in 

each one. 


you are here ► 


187 

































bean creation 


does not exist 


constructor 
setSessionCon+ext() 
ejbCreate() 


Peaw Creation: 

wheH m object becomes a bean 



method ready 



口二一 . 


职 SS 叫 



The proudest moment of my life 
is when the Grand Master Container 
makes me a bean by giving me a context and 
calling my create(). Before that, I’m just an 
ordinary object. But as a bean, I have special 
privileges (besides the secret handshake), 
like the ability to get security 
or transaction info. 


s 


A bean moves from does not exist to method ready (still 
feels creepy... doesn’t it have to exist before it can move}、, 
beginning with a constructor. But the constructor makes 
an object, not a bean. To be a bean, the object needs to be 
granted beanness. 

When an object becomes a bean, it gets all the unique 
privileges that come with beanness, like the ability to get 
security info about the client, or look up special deploy¬ 
time properties in the bean’s special 中 aain JNDI, or get a 
JDBC Connection from a pool managed by the container. 

Why do you care about creation details? 

Because somewhere between the constructor and the 
create () method, the bean is in a Schroedinger’s ten^ state. 

You might have bean initialization code, like getting a 
JDBC Connection, or looking up a reference to another 
bean, that will fail if you run it too early in the bean’s life. 

Writing good bean code means you must know the point 
at which an object becomes a card-carrying bean and what 
that means to you as the developer. 

^1/VcVc Y\oi v/^olc SdKirocd'mjcv -to 

say 七七 rt involves dats ( 办 imal - lovevs be >/av-y>cd) a^d suba-tomit p^ysids. 
Yoy moire m-fo, look (or Read Pivs 七夕心七 _ PKysids m ttc “Wc. 1/VcYe 
sev-ious. Scv-ious -fov- us, anyway. 
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session bean lifecycle 


What happens when a 
bean goes from this: 


object ^ 



to this? 



^av-d-tav-vymg bea^ 


① A SessionContext reference 


Don，t confuse 
a bean context 
with a JNDI 
context! 

Just when you thought it was all so 
clear, you find to your horror that the 
word “context” is overloaded! 

A bean ，s context, like SessionContext 
( 0r EntityContext or MessageDriven- 
Context) is the bean’s special refer¬ 
ence (which extends EJBContext) for 
getting info from the Container. 

This has NOTHING to do with a JNDI 
context A JNDI context, remember is 
a particular “node” on a JNDI virtual 
directory tree. An InitialContext is the 
JNDI context that serves as your entry 
point into the tree structure. In other 
words, the place from which you start 
navigating through the tree. 

Whenever you see the word ''context, 
look closely at the, urn, context of the 
question to figure out to which context 
the question refers — the bean’s EJB¬ 
Context or JNDI context Sheesh! 


A bean’s context (sometimes called EJBContext, 
referring to the superinterface of SessionContext) 
is the bean’s only lifeline to the Container, and it 
lets the bean do things like get security information 
about the calling client, force a transaction to 
rollback, get a reference to the bean’s own home or 
EJB object, and more. 


② A special JNDI Context 

Every bean gets its very own JNDI context, where 
it can find things including resource manager 
connection factories (objects that give you 
connections to resources like a database), other 
beans, and deploy-time constant values that you can 
use to customize your bean’s variables. You’ll learn a 
lot more about that in Chapter 11， where we look at 
the enterprise bean environment (that’s what the spec 
calls the bean’s special JNDI context). 


(D Access to beans and resources 

Just because you got 3. connection to a database 
doesn’t mean you can always use it. Part of being a 
bean is the ability to access a resource (like a database) 
or call methods on another enterprise bean. 
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Special Bean Things 




① A SessionContext reference 

Things you can do with your context: 

■ get a reference to your home 

■ get a reference to your EJB object 

■ get security information about the client 

■ force a transaction to rollback (CMT) 

■ find out if the transaction has already been set to rollback (CMT) 

■ get a transaction reference, and call methods on it (BMT) 


② A special JNDI Context 



a \>cby\s special 

JNPl 


MyPrivatePlace 


Things you can lookup with your special 

JNDI context: 

■ a reference to another bean 

■ a reference to a resource manager connection factory (like 
DataSource) that you can use to get, for example, a database 
connection 

■ deploy-time constant values (kind of like properties) for the bean 
(values set by the deployer that the bean can look up and use 
as variables at runtime). 

■ a reference to an “administered object” resource (which usually 
means a JMS destination) 



③ Access to... 

■ another bean 

_ a resource manager (like a database) 
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You can’t always use aM of 
your beanness … 


Just because you’ve become a full-fledged bean doesn’t 
necessarily mean you can do all of the Bean Things on 
the opposite page (lookup a resource, force a transaction 
rollback, etc.). 


You must know 
WHEN you can 
do specific Bean 
Things and when 
you can’t. 

Be prepared for code or a scenario, 
that shows you a method and asks 
whether you can do a particular Bean 
Thing from that method, given the 

circumstances. 

For example, you might be shown 
the setSessionContext() method of a 
bean, and asked if you，re allowed to 
access a resource (like a database) 
from that method. (You’re not! You 
aren’t in a “meaningful transaction 
context” at that point) 


The things you can do can vary depending on what kind 
of bean you are (Session, Entity, MessageDriven), your 
transaction status, and what kind of method you’re in. 

For example, if you’re a state/w/ session bean, your 
creation is a direct result of the client calling create () on 
your home. If you’re a stateful bean, and you’re in your 
ejbCreate() method, there can be only one reason: a client 
has asked for you to be created. And that means you can find 
out who the client is, by asking your EJBContext (like 
SessionContext) for client security information. 

But if you’re a statebean, your creation isn’t tied to any 
particular client’s request (you’ll learn all about this in a 
few more pages). In fact, if the Container wants to, it can 
create a bunch of stateless beans for the pool before there 
are any clients. And that means a stateless bean cannot get 
security information about the client during ejbCreate(). 
Because there’s no client! There’s only the Container, 
invoking a container callback that’s not part of a client 
call, and we don’t consider the Container to be a client. 
The Container is the boss, not the client. 

And there are some Bean Things that can be done only 
while the bean is in what the Container considers “a 
meaningful transaction context.” You can’t, for example, 
access a database from a method that might not have a 
transaction. 


Some Bean Things are mutually exclusive. If you’re using 
container-managed transactions (CMT) (Chapter 9), 
you must not ask your EJBContext to give you your own 
transaction object. On the other hand, if you’re using bean- 
managed transactions (BMT), you can ask for a transaction 
object, but then you must not ask your context to rollback 
your transaction. You’ll have to rollback the transaction 
yourself, using the transaction object you got from your 
context. 
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Bean creation overview 



(stateful session bean) 
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Session 

Context 


( 3 ) Container links the bean to its 
context and EJB object (calling 
setSessionContext() and ejbCreate()) 


|EJB 

object 


The linking happens when the container calls setSessionContext () and 
ejbCreate() on the bean. Once ejbCreate() returns, the bean is ready for 
‘active duty’ (in other words, ready for business method calls from the client). 
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bean creation 


Object Interaction Diagram (OID) for bean creation 

(stateful session bean) 






bean t 


w 



觀 i 一 
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Writing the three creation-related things 

(stateful session bean) 


① constructor 

Don ! t put anything in the constructor! There’s nothing you would do in 
the constructor that you can’t do in ejbCreate(), so unless your IDE puts 
one in for you, you’re better off leaving the constructor out of your code. 


public class AdviceBean implements SessionBean 


public AdviceBean() 
// no code here!! 

} 






(2) setSessionContext(SessionContext sc) 

Save your context! You get only one chance to grab this reference to 
your SessionContext, so you better assign it to an instance variable. 


private SessionContext context; 

public void setSessionContext(SessionContext ctx) { 


context 


ctx 


5 css , o f^i by ass — %_七、扣…七心 

_bl c . /ou will /s/B\/BK 如。仏饮 io Kav C 

a io youm so you bcttcv- do \i ^ 

put ih ^ Kod ^ b| y ' 


(3) ejbCreate() 

Put all your initialization code here! If it's a stateful bean and the create() 
method has arguments, the Container will pass those arguments into your 
matching ejbCreate() method. You have full bean status now, so you can 
do anything you need to from this method, including things you can’t do in 
setSessionContext() (like get a reference to your own EJB object). 


private String name; 

public void ejbCreate (String clientName) { 

name —— clientName; 乙 

// other code! > 


3 -Pull member of -tKc 
bw society how, so iW\s is 
wheme youll usually put J\LL 
yowr mi-tialiia-tioh Code 
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things you can do durmg creatiow: 


(stateful session bean) 


timeline 



constructor setSessionContext() 


ejbCreate() 


Its W early -to Vo 

arvy-tWi^! VouVc arv object, 
bu-t rvo-t yet 3 bean. 


Use your SessionContext to: 

□ get a reference to your home 

□ get a reference to your EJB object 

□ get security information about the client 

□ force a transaction to rollback (CMT 
beans) 

□ find out if the transaction has already 
been set to rollback (CMT beans) 

□ get a transaction reference, and call 
methods on it (BMT beans) 


Use your SessionContext to: 

□ get a reference to your home 

□ get a reference to your EJB object 

□ get security information about the client 

□ force a transaction to rollback (CMT 
beans) 

□ find out if the transaction has already 
been set to rollback (CMT beans) 

□ get a transaction reference, and call 
methods on it (BMT beans) 


Access: 

3^ your special JNDI environment 

□ another bean’s methods 

□ a resource manager (like a database) 


Access: 




your special JNDI environment 
another bean’s methods 
a resource manager (like a database) 


Note: the word “access” means “do things with”，so when the spec uses 
the phrase “resource manager access”，it means using the resource to 
do whatever that resource is for. So in setSessionContext(), for example, 
you can use JNDI to look up a resource manager connection factory, like 
javax.sql.DataSource, and you can ask the DataSource for a connection 
(myDataSource.getConnection()), but you can’t make a JDBC call on the 
connection reference. You can use your connection in ejbCreate(). 


196 


Chapter 4 




session bean lifecycle 




an aspiring Bean Provider 



/ She doesn't get it... for one thing, I don't put X 
f ANYTHING in my constructor! One time I tried to ^ 
^ do a JNDI lookup in a constructor, to get a database j 
resource factory. It compiled, and didn’t throw an 
exception during the lookup, but at runtime when I tried 
to get a connection, it blew up! The bean hadn't gotten its 
special bean JNDI capabilities yet, so the resource factory 
wasn't really there. There is NOTHING you would do in 
a constructor that you cant do in ejbCreate() instead. 

My best advice is to think of ejbCreate() as the 

constructor for session beans (entity beans are 「 
- - another story). ) 


O 

o 



Bean Provider 
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^ean Use: 

what happens AFTER creation. 



匕“咖 r rW ' 



\}\t 



The only reason I called 
create() on the home is so I could 
get a reference to a bean's component 
interface and do what I REALLY want., 
call a business method. Far as I*m 
concerned, that’s the ONLY reason 
the bean's alive. To service 
ME so I can shop. 


At last... I'm fulfilling 
my destiny. My purpose. 
My raison d'etre*. 


In the method ready state, the bean can run business 
methods. And given that business methods are the bean’s 
highest purpose, the bean can bring all of its beanness to 
bear. In other words, the bean can do more bean things 
from within a business method than at any other point in 
its brief, but meaningful, life. 


We challenge you to find another computer book that uses 
raison d'etre as appropriately as we do. And with that little 
upside down v thing over the e and everything. 
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s Peaw things you caw do within business methods; 


Use your SessionContext to: 


□ get a reference to your home 


□ get a reference to your EJB object 

s/ get security information about the client 

s/ force a transaction to rollback (CMT 
beans) 


SI find out if the transaction has already 
been set to rollback (CMT beans) 


□ get a transaction reference, and call 
methods on it (BMT beans) 


Access: 

□T your special JNDI environment 




another bean’s methods 
a resource manager (like a database) 
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method ready 



ejbPassivate() 


passivated 


ejbActivate() 



Passivation: a statcfuj bea^s chance 
at scalability... 


Are you sure this 
can’t wait until later? I 
was right in the middle of 
shopping... oh well, I guess 
my shopping cart bean will 
still be there when 
were done... 


/ 



arc 


d 、 代刪 




That client doesn’t seem to be 
doing anything. It's too early to kill 
the bean completely; she still might come 
back. But I don’t want the bean wasting 
RAM; I’ll serialize the bean for now, and 
if the client comes back, I’ll just 
deserialize it... 


af UU . 

eS a L S " U 3 



Looks 

like I’m being 
passivated, so I better 
make sure I null out my 
non-Serializable instance 
variables... 


o 

o 




④ 


When the Container decides a stateful bean is wasting 
resources, it’ll call the bean’s ejbPassivate() method and 
then save the bean into temporary storage. 

Why do you care about passivation details? 

Because the Container uses a special set of rules (nearly 
identical to Serialization) to passivate your bean, and it’s 
your job to make sure your instance variables are in a state 
that works for passivation. And it’s just a tiny bit more subtle 
than simply making non-Serializable values transient. 
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Lifecycle overview: bean passivation/activation 


(l) Client doesn’t call any methods 
for a while, so container calls 
ejbPassivate() on the bean. 




( 5 ) Container calls ejbPassivate() on 
the bean, then saves the bean to 
temporary storage (either through 
serialization or something like it). 




(§) Client calls a business method, so 
container activates the bean (through 
something like deserialization), calls 
ejbActivate(), then invokes the business 
method (getAdvice()) on the bean. 



'、bean 

. 2 ... 
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bean passivation 



How does the Container 
know when to passivate a bean? 


A 


譬 

m 


The Container looks for inac¬ 


tivity. If the client hasn’t been doing 
anything for some period of time, 
the Container can choose to passiv¬ 
ate the bean. If it needs to. 


Gee... can you be any more 
non-committal? How long is 
"some period of time” and what 
determines whether the Container 
'needs to' passivate the bean? 

A- 

Jr \ m There is nothing in the spec 
that says you’re allowed to tune 
the parameters for the Container’s 
passivation decisions. But... many 
containers do give you a way to 
set a variety of values.The decision 
might be based on availability of re¬ 
sources, like,"passivate stateful ses¬ 
sion beans only when available RAM 
hits this level...” or,"passivate beans 
only when the number of active 
stateful session beans reaches...” 

And you might be able to set the 
inactivity value for the amount of 
elapsed time at which the Container 
should passivate. 


What if the client crashes? 
Can the server tell? Is there any 
kind of distributed garbage col¬ 
lection or leasing like there is with 
RMI? Or is the server really just 
basing everything on inactivity? 

A- 

According to the spec, there 
is no guarantee of distributed gar¬ 
bage collection, which means you 
should assume that it isn’t happen¬ 
ing. Part of the reason is because an 
EJB client could (at least in theory) 
be a CORBA client rather than a Java 
RMI client. So the whole concept of 
RMI’s distributed garbage collection 
wouldn’t apply. 

And just a quick off-path here: 
distributed garbage collection (dgc) 
or distributed leasing are ways in 
which a server can figure out if 
a client has (with dgc) nulled out 
their reference to the stub, or (with 
leasing) if the client has simply gone 
away, either by shutting down the 
app, crashing, or disconnecting from 
the network. 

The bottom line is that you have to 
assume that the EJB server doesn’t 
support this, so you’re stuck with 
inactivity and perhaps some kind of 
LRU (Least Recently Used) algo¬ 
rithms for selecting who should 
be passivated if resources become 
scarce and the Container needs to 
bring down some beans. 


O 



There’s nothing on the 
exam about vendor- 
specific passivation 
settings or behavior. 


The only thing on the exam about 
passivation is what you’re responsible 
for as a Bean Provider—getting 
your instance variable values in a 
passivatable state (well talk about 
that next). Nothing about passivation 
goes into the deployment descriptor, 
so you don’t need to know how 
passivation parameters are set for 
any particular server. 
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Your job for passivation: 
make your state passivatable! 


When I write my bean class, I 
have to make sure that by the 
time ejbPassivateQ completes, my 
instance variable values are ALL ready 
for passivation. That means the values 
have to be Serializable (or primitive), null, 
or references to one of the special 
things the Container has to take 
care of no matter what. 



When ejbPassivatef) completes，every DOD-frans/enf instdncG 

variable MUST be a reference to one of the following: 

■ a Serializable object 

■ a null value 

■ a bean’s remote component or home interface, even if the stub 
class is not Serializable (in other words, you don’t have to worry 
about it!) 

■ a bean’s local component or home interface, even if it’s not 
Serializable (again, you don’t have to worry) 

■ a SessionContext object, even if it’s not Serializable 

■ the bean’s special JNDI context, or any of its subcontexts 

■ the UserTransaction interface (something you can get from your 
SessionContext—we'll see that in the transactions chapter) 

■ a resource manager connection factory (like, an instance of 
javax.sql.DataSource) 



You have to 
know these 
for the exam- 

,might see a question that 
)ws you a class and an 
Passivate() method and asks 
j jf it would work or not 
he method is empty, you have 
look at the instance variables to 
0 jf they’re all OK as they are. 
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activation passivation 


Implementing ejbActivate() and ejbPassivate() 


ejbPassivate() 

Make sure your instance variables are ready for passivation. Most 
of the time, you probably won't have any code in ejbPassivate(), simply 
because all of your instance variables meet the criteria defined on the 
previous page (e.g. reference to a SessionContext, or a bean’s component 
interface, or a Serializable object, etc.). 


public void ejbPassivat*^ n i 
connection = null; 



ejbActivate() 

Reacquire your non-Serializable resources, or do whatever it takes 
to restore your state for use. If you’re running in ejbActivate(), there 
can be only one reason: the client called a business method. So in your 
ejbActivate() method, you must make sure you get ready for the business 
method call that’s about to happen.Chances are, this method will be 
empty, for the same reason as ejbPassivate(). But if you did null out non- 
Serializable references, then ejbActivate() is the place to get them back. 

public void ejbActivate() { 

try { 

connection = myDataSrc.getConnection (); 

}catch (Exception ex) {...} 
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Can’t you just mark your non-Serializable variables 
transient? Isn’t that what transient is for 飞 

A- 

You could, yes, because the Container is required to 
follow the rules for Serialization when it passivates a bean 
(even if the Container chooses to use something other than 
serialization to get the job done). 

But", there’s a little teeny comment in the spec which 
says that there’s an exception to the rule that passivation 
behave just like serialization.The exception is that while 
serialization is required to bring back transient fields with 
default values, passivation doesn’t guarantee that! 

What does this mean? Think about it. It means you can’t 
rely on transient to give you back your defaults, so after 
activation, you could end up with, well, anything in a 
variable that’s marked transient. 

So, you are free to use transient, and it can make passivation 
more efficient, but the implication is — reset your transient 
variables yourself, in ejbActivate(). 


What if I have a non-Serializable value that I really 
need to maintain during passivation? If I can’t save it, how 
will I know what to set it back to in ejbActivateO? 

A- 

This is a classic serialization issue, not specific to 
passivation.The usual trick is to interrogate the non- 
Serializable object to get all the important state out of 
it, and stick that state into instance variables that are 
Serializable.Then during ejbActivateO, use the values you 
were able to save to reconstruct the non-Serializable object 
so that it’s identical to the one you had before passivation. 
For example, imagine you have a Dog bean with a Collar 
variable, and the Collar isn’t Serializable. In ejbPassivateO, 
call getters on the Collar to retrieve the values that matter 
(like getColor(), getSizeO, etc.). Save those values in instance 
variables in the bean, then in ejbActivateO instantiate a new 
Collar and use the Collar attributes you saved as arguments 
to setters on the new Collar object. 



You’re responsible for making sure that when 
ejbPassivate() completes, your instance 
variables are in one of the states we listed a 
couple of pages ago. Don’t look now! See if 
you can work out which of these will be safely 
passivated... 


□ reference to a java.net.Socket object 

□ reference to a javax.sql.DataSource 

□ reference to a bean’s Remote component 
interface 

□ reference to a bean’s JNDI context 

□ reference to a java.sql.Connection 

□ reference to a javax.ejb.SessionContext 
object 

□ a transient variable with a null value 

□ a non-transient, Serializable variable with 
a null value 

□ a transient variable with a non-null value 


□ a non-transient, non-Serializable variable 
with a null value 

□ a non-transient, non-Serializable variable 
with a non-null value* 


*We were going for a personal best (PB) in the 
number of times in which we could use the 
word ‘non’ in a single statement. 
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passivation and transactions 



WARNING: 

A stateful session 
bean will NEVER be 
passivated while 
the bean is still in a 
transaction! 


I have been 
sitting here, like, 
forever, waiting for this 
stupid transaction to 
finish... 



The spec lets you begin a transaction in one method of a stateful 
session bean, but end the method without ending the transaction. 
This is almost always a really stupid thing to do. For starters, you 
could never guarantee that just because a client calls the method 
that begins the transaction, the client will at some point call the 
method that ends the transaction (in either a commit or rollback). 
But the main reason is that the longer your transactions, the better 
your chances of bringing your server to its knees (and that holds 
regardless of the bean type). For stateful session beans, leaving a 
transaction open means the bean will not be passivated, no matter 
how long it’s been since the client did anything with it. We’ll look at 
this more in the transactions chapter, but for now, understand that 
stateful beans in a transaction won’t be passivated! 
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things you caw do iw ejbActivateO and ejbPassivateO 


ejbPassivateO 

ejbActivate() 

Use your SessionContext to: 

Q get a reference to your home 

□ get a reference to your EJB object 

□ get security information about the client 

□ force a transaction to rollback (CMT 
beans) 

□ find out if the transaction has already 
been set to rollback (CMT beans) 

□ get a transaction reference, and call 
methods on it (BMT beans) 

Use your SessionContext to: 

□ get a reference to your home 

□ get a reference to your EJB object 

□ get security information about the client 

□ force a transaction to rollback (CMT 
beans) 

□ find out if the transaction has already 
been set to rollback (CMT beans) 

□ get a transaction reference, and call 
methods on it (BMT beans) 

Access: 

[3 f your special JNDI environment 

0 another bean’s methods 
_ a resource manager (like a database) 

Access: 

□T your special JNDI environment 

0’ another bean’s methods 
_ a resource manager (like a database) 
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Peaw Removal: 
wheH bea^is die 


As a stateful bean, 

I'm a personal slave to 
the client, and when shes done 
with me, I’m tossed out like 
so many AOL disks. Sometimes 
they don't even let me say 
goodbye... 



M _ bean throws system exception 

does not exist (unchecked, uncought) 



A session bean stops existing for 
one of three reasons: 


1. the client calls remove() 

2. the bean times out 

3. the bean throws a system exception 


But... there’s another question to ask: when the bean times 
out, was it active or passive? If the bean is active, the 
Container deals with it in the same way it deals with client 
remove() calls—the bean gets an ejbRemove() call and is 
then killed. But if the bean was passivated when it times out, 
the Container sends it straight to the does not exist state 
without calling ejbRemoveQ. 
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session bean lifecycle 


Lifecycle overview: removing a stateful bean 

Client calls remove() on an active (i.e. non-passivated) bean 


Client calls remove on the 
component interface (or calls 
the remove() method in the home 
interface, that takes a Handle). 




( 2 ) Container calls ejbRemove() 
on the bean. 
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bean removal 


Lifecycle overview: removing a stateful bean 

Bean times out while active 




Client doesn’t make any calls to the 
bean’s component interface for a 
long time (whatever the Container 
considers a “long” time). 


No activity! 


(2) Container decides to kill the 
bean, and calls ejbRemove() 


on the bean. 
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session bean lifecycle 


Lifecycle overview: removing a stateful bean 

Bean times out while passivated 


The client doesn’t call any methods 
on the bean’s component interface 
for a long time AFTER the bean has 
already been passivated. 




No activity 


(2) Container decides to kill the bean, 
but does NOT call ejbRemove(). 
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bean removal 


Lifecycle overview: removing a stateful bean 

Bean throws a system exception 


The bean throws a system 
(unchecked) exception while 
executing a method. 




Exception!! 




212 Chapter 4 
































session bean lifecycle 


Complaints about bean removal 



How am I supposed to 
know you re coming back? If I 
don’t use timeouts, before long HI be 
FULL of rusty old abandoned shopping 
carts. Sooner or later, I have to 
assume that you re never coming 
back. Sorry, but I really 
have no choice. 

C/ 



I don’t see why you 
can't call ejbRemove() 
on a bean when you re going to 
kill it, regardless of the reason. 
What good is ejbRemove() for 
putting in clean-up code if it 
might not be called? 



First of all, you honestly expect me to bring 
a bean OUT of passivation just to kill it? Talk 
about a waste of overhead! Sheesh, you should 
know better, if you care about performance. And 
it’s not that big of a deal ― just put your clean-up code in 
both ejbRemove() AND ejbPassivateO, and you're safe. 
And with exceptions, think about it...do you really want 
to run your clean-up code on a bean whose state could 
be seriously corrupt at this point? If a bean throws 
a system exception, I’m just gonna log it and 
put it out of its misery. 
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implementing ejbRemovef) 


Implementing ejbRemove() 


ejbRemove() 

Release any resources, or do whatever clean-up you need to do be¬ 
fore the bean dies forever. Much of the time, your ejbRemove() method 
will be empty, because if your bean does use resources, it most likely will 
acquire and release the resources in each business method. But if your 
design does call for keeping resources open throughout the bean’s life, 
then you need to free them up here! 


public void ejbRemove() { 

try { 

myResource.close(); 

} catch (Exception ex) { 

} 

an alternative... 




4 




Call a cleanUp() method from both ejbPassivate() and ejbRemove(). 

Given that your bean could be removed without an ejbRemove() call, if it 
times out while passivated, you should have both your ejbPassivate() and 
ejbRemove() methods perform the same clean-up. Since scarce system 
resources are seldom Serializable anyway, you’re probably already taking 
care of them in ejbPassivate(). 


public void ejbRemove() { 

this.cleanup(); 


public void ejbPassivate() 
this.cleanup(); 




private void cleanup () { 

try { 

myResource.close(); 

} catch (Exception ex) {...} 
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Missed ejbRemove() calls 


Wait a minute... there's 
still something wrong here. 
What happens if the bean throws 
an exception? Then I still won't 
get my cleanup code to run. 
Won't I still get into trouble? 








Well, um, yes. Yes, you could still 
be in trouble in that case. But this is really YOUR 
responsibility to deal with. Let's say you temporarily 
save someone's shopping info to a database, so that if 
the server crashes while the person's shopping, you have a 
means of still recovering their cart (until the bean times out). In 
ejbRemove() youd delete the row in the database for this client. 
But since you might not get that ejbRemove() call, sooner or 
later you're gonna need some way to go through and do periodic 
cleanups on that data. There's nothing in the spec that can 
help you here. If s up to YOU to deal with the potential 
consequences of missed ejbRemove() calls! 


You must be able to 
recognize scenarios in 
WatCh it! which ejbRemoveO will 

be missed! 

The exam expects you to know that there are 
three circumstances under which a bean wi 
NOT get an ejbRemoveO call: 

1. Server crashes. 

2. Bean times out while passivated. 

3 Bean throws a system exception. 

If any of these happen, your clean-up code 
will not run. If you follow the suggest,ons on 
the previous page, and put clean-up=n 
both ejbPassivateO and 

you^e probably OK for problem #2 (^ eout 
while passivated), but youll still have todeal 
with a server crash or bean system exception. 

And don’t expect a simple, obvious question 
like “Will a bean miss an ejbRemoveO if 
a system exception is thrown?” You might 
have to consider a design scenario for 
example, and figure out if there C0U J d b = 
problem, based on your knowledge of missed 

ejbRemoveO method calls. 


J 
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ejbRemovef) bean things 


^ean things you can do m ejbRemoveO 


Use your SessionContext to: 

□ get a reference to your home 

□ get a reference to your EJB object 
s/ get security information about the client 

□ force a transaction to rollback (CMT 
beans) 


□ find out if the transaction has already 
been set to rollback (CMT beans) 

□ get a transaction reference, and call 
methods on it (BMT beans) 


Access: 

□T your special JNDI environment 




another bean’s methods 
a resource manager (like a database) 


The bean things you can 
do in ejbRemove() are 
exactly the same as the 
bean things you can do in: 

• ejbCreate() 

• ejbPassivate() 

• ejbActivate() 
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ImplemeHting the Advice^ea^ as a statcFUL bean 


So far, the AdviceBean we’ve written hasn’t 
needed to be stateful. It doesn’t keep or use 
any client-specific state, so it doesn’t need a 
create () method with arguments. But what if 
we did want to make it a stateful bean? What if 
the business logic needed to, say, keep a record 
of the conversation it’s having so that it never 
gives out the same advice more than once in a 
session? Even if the choice of an advice string is 
purely random, if you want to ensure the advice 
isn’t repeated during a session, you’ll have to 
keep track of it in an instance variable. 

And you might have other changes, too, like 
making the create methods take arguments that 
contain the type of advice the client is looking 
for, or some other kind of preference. In that 
case, each time the client made a method call, 
you’d want to check the status of that client- 
supplied creation initialization preference, 
and tailor your advice based on the value set 
during the bean’s ejbCreate(). Later in the 
book, we’ll look at a more elaborate version of 
this AdviceBean, but for now, we’ll make just a 
subtle change to make the bean stateful. 


Things you caw add if the bean is stateFUL 

You can have more than one create method 


The create method can have arguments. 


( 3 ) The bean can be passivated, so you 
can write code in ejbPassivate() and 
ejbActivate(). 



What happens if you put code in ejbPassivateO or 
ejbActivateO and the bean is stateLESS? Will it compile? 
Will it deploy? 

A- 

You can certainly put code in ejbActivateO or 
ejbPassivateO, regardless of whether the bean is stateless 
or stateful, even though it will never be called if the bean 
is stateless. 





You know that the bean class is going to 
change, but what about the client and the 
two interfaces? Do one or more of those 
have to change? Really think through the 
implications before you turn the page. 


Think about it. Look at the SessionBean interface. Notice 
that there isn’t a separate StatefulSessionBean interface 
and StatelessSessionBean interface.There’s just Session- 
Bean, and both stateless and stateful beans implement it. 
So there’s nothing in your class that specifically says your 
bean is stateless. It’s only at deploy-time, when you tell 
the deployment descriptor that the bean is stateless or 
stateful, that it actually matters. 


In fact, you could write a bean that has only a no-arg cre¬ 
ate, and keeps no client state, and you can deploy it with 
either setting 一 stateless or stateful 一 and it will work, as 
long as you’ve taken care of passivation and activation. 
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stateful session bean code 


AdviceStateful^ean code 


package headfirst; 
import javax.ejb.*; 

public class AdviceStatefulBean implements SessionBean { 
private Ses sionContext context; 




st、U ^ CSS '° 





private String userName; 

TWis time, y/c keep 

sla-tc (m -tKis cast, -tKc ar^umc^-t 

tl. 咖 t sc^ds -to -tKc Crtait method) 


public void ejbActivate() { 

} 

public void ejbPassivate() { 


public void ejbRemove () { 

} 


o( -the 4u\r £cssiohBcah doh-taihcv dallb^b 4-u i 
the dohtexi because wc wahl VnU i 3 / j , ^ ^ 

yo 叱 b^ause i, ^osi ^ ^ 

•pi 以， ittiiv ，h °°^ you11 w 


public void setSessionContext(SessionContext ctx) 
context = ctx; 


public void ejbCreate(String 
userName = name; 


name) { 丁卜 s 6 广 wV Ast NOT 




bctavAsc 


public String getAdvice() { 

return userName + '、，my advice is: 


Advisor.getAdvice(); 



ihe busi^g ss /, 


' 織 ㈣ 

\ci 'fovA 
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AdviceStateful^ean CLIENT code 


The stateful version of the client adds two things not in the stated version: 

1. We^re passing an argument to the create() method. 

A stateful bean can (and often does) have arguments to create methods, so that 
the client can pass in client-specific state for the bean to save and use in later 
“conversations” with the client (i.e. later method calls from that client). 


2. We^re calling remove() on the component interface. 

It’s polite for the client to tell the Container that she’s done with a stateful session 
bean. And now you know why. Without the remove () call, the Container will hold on 
to the bean, wastefully, until the bean times out. So in this case “polite” really means 
“improves scalability”. 


import javax.naming.*; 
import javax.rmi.*; 
import headfirst. * ; 
import javax.ejb.*; 

public class AdviceStatefulClient { 

public static void main(String[] args) { 
new AdviceStatefulClient().go(); 

} 

public void go() { 
try { 

Context ic = new InitialContext(); 
Object o = ic.lookup(''StatefulAdvisor") 


You must be able to 
recognize whether 
the client is for a 
stateful bean- 

You must be able to look at client code, 
like this, and know whether the client s 
bean is stateful. If the client calls a 
no-arg createQ, there’s no way to know 
whether it IS stateless, but at least you 
know it MIGHT be. If the create has 
args, or a name other than create 。 
(like: createAccount()), you know the 
bean must be stateful. 


AdviceStatefulHome home = (AdviceStatefulHome) PortableRemoteObject.narrow(o, 

AdviceStatefulHome.class) 

AdviceStateful advisor = home. create (''clover^) 

TW 一⑽， 

System.out.println (advisor.getAdvice ()) ; ' d j 


advisor.remove(); 

} catch (Exception ex) { 

ex.printstackTrace(); 


-to td! the Co^i^ wcVe 

do„e ihc bca, (so tKc Co^,^ ^ ki || 


又七 his is a poor y；ay {jo y/ould probably wvrte 

a real - v/ovld tWt^i bo taicM kmds of 
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ir^irpen your pencil 


Do the interfaces have to change when it goes from 
stateless to stateful? 


Look at the two interfaces below, for the state/ess version 
of the Advice bean. If needed, make any adjustments to 
the code in either or both of the interfaces, for what (if any¬ 
thing) needs to change to make this work with the revised 
siaieful version of the bean. 


package headfirst; 

import javax.ejb.*; 

import java.rmi.RemoteException; 

public interface AdviceHome extends EJBHome { 

public Advice create() throws CreateException , RemoteException; 


package headfirst; 

import javax.ejb.*; 

import j ava. rmi. RemoteException ; 

public interface Advice extends EJBObject { 

public String getAdvice() throws RemoteException; 
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Peployiwg a stateful beaw 

The only difference between deploying the stateful 
Advice bean and the stateless version (besides the 
file names and JNDI name) is in the deployment 
descriptor setting that defines whether the bean 
is stateless or stateful. Using the RI deploytool, 
remember, you set this using the deploytool’s New 
Enterprise Bean Wizard — the thing that walks you 
through the settings that it then uses to output the 
XML deployment descriptor. 


0 


New Enterprts 


Please rlhcHJse Lhi> type uf enterprise bman ill 急 L yuu hj 
L he bean. Yqu Lari lIiqo^e lu pr dv\ dt Dnly IucaI InLerfi 
□ pLi-umi ： Ily, you tan pr^vido ^ dcsc.ripLi[}n arid fn 


B 拉 n Type 

凝 Entity 

O yessage-Dfiven 

® Session 



Youll have io -this h> ^iaicUH 


_BULLET POINTS _ 

■ Container callbacks indicate key milestones in a bean’s 
life. 

■ As a Bean Provider, you’re responsible for implement¬ 
ing the container callbacks in your bean class. 

■ Container callbacks come from two places: the 
SessionBean interface, and the home interface. The 
compiler forces you to implement the SessionBean 
interface, but the callbacks related to the home are your 
responsibility, and the compiler won't know, since your 
bean class doesn’t implement your home interface. 

■ A stateful session bean can be in one of three states: 
does not exist (yes, that’s a state), method-ready, and 
passivated. 

■ When a bean transitions from does not exist to method- 
ready, its constructor is called, followed by setSession- 
Context(), and finally the bean’s ejbCreate(). 

■ A bean instance has specific Bean Things that it can 
do, but none are available during the bean’s construc¬ 
tor, because at that point it is an object but not yet a full 
bean. It doesn’t yet have its beanness. 

■ Some of the Bean Things a bean can do include: get a 
reference to its home or EJB object, learn or affect the 
status of the transaction, get security information about 
the client, and access a resource such as a database. 

■ When a stateful bean is passivated, it’s put into second¬ 
ary storage, possibly through serialization. You must 

be sure, by the end of your ejbPassivate() method, that 
your instance variables are ready for passivation. 

■ The Container calls ejbRemove() on a bean when the 
client calls remove(), fora stateful bean, or when the 
Container wants to reduce the size of the pool, for 
stateless beans. If a passivated bean times out, the 
Container will kill the bean without invoking ejbRe- 
move() 

■ A bean can also miss an ejbRemove() call if there’s a 
container crash or the bean throws a runtime exception. 
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stateful vs. stateless 


Compared to stateful beans, stateless beaws 
have a simple life 

Statebeans have a much simpler existence. They’re born (created), 
they’re thrown into a pool with others of their kind, they run business 
methods for any client who asks, and they might eventually die. They aren’t 
passivated, they don’t keep client-specific state, and their creation and 
destruction (removal) aren’t tied to the whims of the client. Compare the 
difference between the lifecycle of a stateful vs. stateless bean: 

The bean lifecycle (special moments in a bean’s life) 

Statefuj session beans 

■ Bean creation (when the client wants a bean) 

■ Bean use (when the client calls a business method) 

■ Bean passivation (the bean is put to sleep to conserve 
resources) 

■ Bean activation (the bean wakes up to service a business 
method from the client) 

■ Bean removal (when the client is finished with the bean or 
the bean times out) 


Stateless session beans 

■ Bean creation (when the container wants to make a bean) 

■ Bean use (when the client calls a business method) 

■ Bean removal (when the container decides there are 
too many beans in the pool, or the bean throws a system 
exception.) 
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session bean lifecycle 


Comparing the lifecycles of stateful 
and stateless session beans 


Stateful 

M _ bean throws system exception 

does not exist (unchecked, uncaught) 



Stateless 


M _ bean throws system exception 

does not exist (unchecked, uncaught) 
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stateless beans 


Client calls create on a stateless session bean home 



(§) Container sends the client a stub 


to the EJB object. 
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session bean lifecycle 


Session bean creation is not 
related to the client 


(T) Container constructs the 
SessionContext object and 
the bean instance, then calls 
setSessionContext() on the bean 




( 5 ) Container puts the bean (which is 
now linked to its own context) in 
the pool for that bean type. 
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business methods 


Business method cal 


(T) Client invokes a business method 
on her previously-acquired EJB 
object stub. 




( 5 ) Container pulls a bean out of the 
pool and links it with the client’s 
EJB object. 




fEJB 

bject 



(§) Container invokes business method 
on the bean (1), the bean returns 
from the method (2), then Container 

sends bean back to the pool (3). 

_ • • • • 


y '7\ Stub 


: client 
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session bean lifecycle 


Object Interaction Diagram (OID) for bean creation 

stateless session bean 


When the client calls create 






client 






create() 


-►I 


new 


i 


and at a completely different / unrelated time: 
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session bean things 



things you can do from stateless bean methods 


constructor 


■ 


nothing 


setSessionContext() 

Use your SessionContext to: 

□ get a reference to your home 

□ get a reference to your EJB object 

□ get security information about the client 

□ force a transaction to rollback (CMT 
beans) 

□ find out if the transaction has already 
been set to rollback (CMT beans) 

□ get a transaction reference, and call 
methods on it (BMT beans) 

Access: 

□f your special JNDI environment 

□ another bean’s methods 

□ a resource manager (like a database) 


business method 

Use your SessionContext to: 

□ get a reference to your home 

□ get a reference to your EJB object 

s/ get security information about the client 

force a transaction to rollback (CMT 
beans) 

3 find out if the transaction has already 
been set to rollback (CMT beans) 

□ get a transaction reference, and call 
methods on it (BMT beans) 

Access: 

□T your special JNDI environment 
M another bean’s methods 
_ a resource manager (like a database) 


ejbCreate() ， ejbRemove() 

Use your SessionContext to: 

get a reference to your home 
get a reference to your EJB object 

□ get security information about the client 

□ force a transaction to rollback (CMT 
beans) 

□ find out if the transaction has already 
been set to rollback (CMT beans) 

□ get a transaction reference, and call 
methods on it (BMT beans) 

Access: 

□f your special JNDI environment 

□ another bean’s methods 

□ a resource manager (like a database) 


Unlike statcFUL a 
b 咖 W 七 y 七 ^all^ m^ro m 

c\bCvcatcO, bctausc 七 We IS 广叫咖七 

aiso^ated ^ sbWess bea, s 

⑽ aW vb 七 k Co 山 m 广 

铣 a 七 dc^dcs bo trtait tv>c bcai., 
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How come 
ejbPassivate() and 
ejbActivate 。 aren't called 
when the bean goes in and 
out of the pool? 


① 



There's no need! Beans stay 
awake when they're in the bean 
pool. For performance, I keep 
the beans as whole living objects on the 
heap, not serialized objects that I’d 
just have to reactivate each time a 
client calls a method and I need 
a bean to service it. 





Well then how do 
you get scalability, if 
all the beans in the pool 
are taking up space on 
the heap? 





^Rememb 


\ber, with stateless 
beans I don't need one per 
client— I need only one per client-in-the- 
middle-of-a-business-method-call. In other words, 
I need just enough stateless beans to service the 
methods actually executing, and not one per every 
client who happens to have a reference to an EJB 
object! Clients spend far more time between 
method calls than actually in method calls. 


o 

o 


-™ & 
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writing session beans 



Writing a Session Peaw: 
your job as Provider 


You put THREE kinds of methods 
in the bean class: 


(T) HOME things: ejbCreate() methods 

Write an ejbCreate() method in the bean to match each 
create() method in the home interface. 


(2) COMPONENT things: business methods 

Write a business method in the bean to match each 
method in your bean’s component interface. 



«interface» 

SessionBean 

setSessionContext() 

ejbPassivate() 

ejbActivatef) 

ejbRemovef) 


③ 


SESSION BEAN things: container callbacks 
from the SessionBean interface 

Implement each of the four methods from the 
SessionBean interface, which your bean must implement 
in the official Java way (i.e. using the implements 
SessionBean declaration either in your bean class or one 
of its superclasses) 


貧 ^^rpen your pencil 


Of the three types of methods you 
put in your bean, check off the ones 
the compiler cares about. 


Compiler-checked? 

□ Methods to match the Home interface 

□ Methods to match the Component interface 

□ Methods from the SessionBean interface 
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arpen your pencil 


Given the following interfaces, write the bean class code (you can leave 
the method empty) at the bottom of the page. Pay special attention to 
the Home create method … what does it take to ‘match’ this in the bean? 
Will it have the same return type? Hints are at the bottom of the page. 


import javax.ejb.*; 

import java.rmi.RemoteException; 

public interface KennelHome extends EJBHome { 

public Kennel create(String custID) throws CreateException, RemoteException; 


import javax.ejb.*; 

import java.rmi.RemoteException; 

public interface Kennel extends EJBObject { 

public KennelLease placePet(Pet p) throws RemoteException; 

public void renewLease (KLease lease) throws RemoteException, ExpiredException; 
public Pet getPet(KLease lease) throws RemoteException, DeadPetException; 


Write the bean class here: 


^aoejja^u! 9i |； u; spoil 押 lu 8i |； uo pajepap aie jbli; 1 ssb\o uo!j 


-B ； U0LU0|dlU! 9L |； U ； SUO! ； d0OX0 0LUBS 0L |； 0JB|O8p JSniU 806^0^! UB jO J8 ； U8LU8|dlU! 0L |； SABS ； BL|J 8|nj 
B 8ABL| BABp S90Q 'UOIJB0JO 6uunp UB8q 91]} LUOJj >|0Bq 6U|L|；AUB p88U J ( US80p J8U|B ； U00 9L] 丄 -0OBJ. 
-J8 ； U| 0LUOL| 8L |； U| 8U0 8L |； UBL]J 8LUBU JU8J8Jj!P A 叫 6!|S 6 SBL| UB8q 8L |； U| pOL^LU 0LUOL] 9L| 丄 ： S ； U|H 
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Rules for the HOME methods: home interface 


① Local home interfaces must return the local component interface, and 
Remote home interfaces must return the Remote component interface. 

public interface AdviceLocalHome extends EJBLocalHome { 
public AdviceLocal create () throws CreateException; 


public interface AdviceHome extends EJBHome { 
public Advice create () throws CreateException, 

RemoteException; 


( 2 ) Every create method in the home interface must declare a 

CreateException, regardless of whether the interface is local or Remote. 

You can also declare your own application (checked) exceptions. 

public Advice create () throws CreateException, 

NoAdviceException; 

③ Local home interfaces must extend EJBLocalHome, and must NOT 
declare RemoteExceptions. 

public interface AdviceLocalHome extends EJBLocalHome 

public AdviceLocal create () throws CreateException; 


④ Remote home interfaces must extend EJBHome, and must declare 
RemoteExceptions on every method. 

public interface AdviceHome extends EJBHome { 
public Advice create () throws CreateException, 

Remo teException; 


⑤ Stateless beans can have only one create() method, and it must NOT 
have arguments! 

public Advice create ()throws CreateException; 


⑥ Stateful beans must have one or more create() methods, and are NOT 
required to have a no-arg create(). The create() methods must start 
with the string “create”，and can be overloaded. 

Foo createBigFoo () 

Foo create () 

⑦ Arguments and return types for Remote home interface methods must 
be legal RMI-IIOP types (Serializable, primitive, Remote, or collec¬ 
tions or arrays of any of those). 


Tke return type of a 
lioitie create metlioct 

must ALWAYS 

Le tlie component 
interface type. 


〈〈 interface 〉〉 

KennelHome 


Kennel create(String id) 



TK'IS must be -tKc 
m-tev-fate Rcmo-tc 

Komes must Re¬ 
mote 七 mWfate 

lo£>dl KomCS irwUst 

v-ctuvi^ lo£>dl 灼 C 灼七 
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Rules for the HOME methods: bean class 


Every create method in the home must have a matching eyibC reate 
method in the bean class. The ejbCreate methods in the bean must 
have a void return type. 

public void ejibCreate () { } 


② 


The ejbCreate methods must be public and must NOT be marked 
final or static. 


③ You do NOT have to declare the exceptions declared in the home inter¬ 
face, unless you might actually throw those exceptions from your own 
methods, although it is often good practice to declare CreateException. 
You MUST not declare RemoteException in your bean class, EVER. 

public void ejbCreate() { } // no declared exceptions, 

// because we don r t actually throw any 


④ You must NOT declare any application exceptions (i.e. checked 
exceptions) that were not declared in the home interface for that 
matching create method. 


public void ejbCreate () throws FireException { } 

// not legal unless FireException is declared on the 
// home interface create method!! 


⑤ 


Stateless beans must have only one ejbCreate(), and it must have no 
arguments. 


public void ejbCreate () { } // must look like this! 


Every create in tlie 
lioitie must liave a 
matcliiiig ejbCreate 
in tlie Lean class 
(voict return type). 



"TKc bed^ KomC methods 

mUS-t maUK i\\t KowC 
methods, 

you "tKc dass 
mc-tKods y/'i-LKW 

■bo 'cjbCv-ca-tc 


Stateful beans must have one or more ejbCreate methods (match¬ 
ing the methods of the home interface), and must start with the string 
“ejbCreate”. 

HOME: 

public Foo createBigFoo() throws CreateException; 

BEAN: 

public void ejbCreateBigFoo() { } 
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Rules for the BUSINESS methods: component interface 

r 


① 


Business method names must not begin with the string “ejb”. 


Arguments and return types for Remote component interface methods 
must be legal RMI-IIOP types. That means Serializable, primitive, 

Remote, or an array or collection of any of those (as long as the collection 
implementation class is itself Serializable). 


Remote component 
interface metliocts 


public String getAdvice()throws RemoteException; 

// String is Serializable, so this method could be 
// in a Remote component interface 


public Socket getTheSocket(); 

// Socket is NOT Serializable, so this method must 
// NOT be in a Remote interface (local would be OK) 


must liave RMI-IIOP 

types as arguments 
and return types. 


String doSomething(int i) 


Local component interfaces must extend EJBLocalObject and must NOT 
declare RemoteExceptions. 

public interface AdviceLocal extends EJBLocalObject { 

public String getAdvice(); 


Remote component interfaces must extend EJBObject and must 
declare RemoteExceptions on every method. 

public interface Advice extends EJBObject{ 

public String getAdvice() throws RemoteException; 


TK'IS mrtKod v/ould be Ic^l 
•m c'rtKcv- a Rcmo-tc ov \ota\ 
because i\\t a^r^u- 

a^d type 狄 c 

le^al RMI-IIOP 


⑤ You must not expose the local home or component interface of a bean 
through a Remote component interface method. In other words, you 
can’t have a local interface as the return type or argument type in a 
Remote component interface method. 
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w Rules for the BUSINESS methods: bean^class 

r 一 


① Business methods must be declared as public, and must NOT be 
declared as final or static. 

public void doBigThings() { } 

( 2 ) Method names must not begin with the string “ejb”. 

③ You must NOT pass “this” as an argument or return value. Remember, 
you don’t want to give out a reference to the bean! Everybody must go 
through the EJB object (later, we’ll see how to do that). 

public void doStuff(this); // not legal 

// from within a bean method! 


Business metkocts must 
not tkrow application 
(dkeckect) exceptions 
tliat aren’t cteclarect 
in tlie component 
interface. 


② 


③ 


Arguments and return types for Remote component interface methods 
must be legal RMI-IIOP types. That means Serializable, primitive, 

Remote, or an array or collection of any of those (as long as the collection 
implementation class is itself Serializable). 

public String getAdvice() { } 

// String is Serializable, so this method could be 
// in a Remote component interface 


public Socket getTheSocket() { } 

// Socket is NOT Serializable, so this method must 
// NOT be in a Remote interface (local would be OK) 

You do NOT have to declare the exceptions declared in the component 
interface, unless you might actually throw those exceptions from your 
own methods. You MUST not declare RemoteException in your bean 
class, EVER. 

public String getAdvice() { } // no declared exceptions 

// because don r t actually throw any 


SessionBean 
extends 
EnterpriseBean 

■here，s nothing in there, BUT... 

: nterpriseBean is Serializable. 

that means your bean is 
wtomatically Serializable, without 

/our having said so. 
ifyou have a scenario where you 
need to recognize if a bean is 
Serializable, IT IS, even though 
you don’t see the bean class say 
implements Serializable . 


^ 4 ) You must NOT declare any application exceptions (i.e. checked 

exceptions) that were not declared in the component interface for that 
matching business method. 


public void getAdvice() throws AdviceException { } 

// not legal unless AdviceException is declared on the 
//component interface version of the method! 
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iJl 

Other rules for your bean class 

■ || \ 

• |i \ 

① The class must implement javax.ejb.SessionBean, either directly 
or indirectly. 


public class AdviceBean implements SessionBean 


② The class must be public, and cannot be final or abstract. 

③ The class must have a public, no-arg constructor. (That’s what the 
Container has to use). We recommend just letting the compiler insert 
the default constructor, since you do NOT want to put code in the 
constructor. 

public Advice() { } // valid bean constructor 


④ You must NOT have a finalize。method in your class! 


⑤ 


⑥ 


⑦ 


⑧ 


The class is not required to (but is allowed to) implement the bean’s 
component interface. (We talked earlier, remember, about why you 
probably don’t want to “officially” implement your component interface.) 


Your class MUST implement the matching home and component interface 
methods (i.e. an ejbCreate for every create in the home, and a matching 
business method for every method in the component interface). 

If the bean is stateful, it can, optionally, implement the 
SessionSynchronization interface. (This interface gives the bean 
three more callbacks related to transactions, which we’ll look at in the 
transactions chapter.) 

Your bean class can have a superclass. In other words, you can use 
normal Java inheritance with your bean class. (You just don’t get any 
special bean-specific inheritance, remember.) 


Your bean class 
can have other 
methods 

DU r bean class has to have the 
iree types of methods: stuff from 
home (ejbCreates to match 
reates), business methods from 
be component interface, and the 
our SessionBean methods. But 
10 thing stops you from having your 
own non-exposed “helper”’methojs ， 
Bn d those methods do NOT need 
to be public. 
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The difference between create and ejbCreate 


home 

interface 


七 he Y^ttds b> yt 

m-tcv-fa^e 


public Kennel create() throws CreateException , RemoteException,PetException 


bean 

class 


dor/t -fovact tKc 


\ 


7 ° - y/ 

public void ejbCreate() throws PetException { 


but the 匕 ohtaihe\r docsh'-t heed 

-f\rom -the beah 


I'm not sure I 
understand why the 
return types are different 
between the bean and 
the interface... 


The Container 
might not need 
anything from the bean, but 
the home damn well better 
give ME the component 
interface. That’s the only 
reason I’m here... 







When I call the 
bean's ejbCreate method, I 
don't NEED anything from the 
bean, thank you very much, so use 
void for the return type. (This will all 
change with entities, though... so 
be prepared.) 


% 
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session bean watch-its 


VSm i ust remove，and 
ejbCreate vs. c ； eate. 

rue 0 「 false: the Container calls a 
FALSE! The bean doesn’t HAVE a 

r = 0 h v 0 e d () methQd ，⑽ ㈣ _ 抓⑽ 0 

invokes the createf) method? The client 

㈣. Who Evokes 

^okesremovep? (client). 


in 


You can have 
a return in an 
ejbCreateO- 

You KNOW that an ejbCreate() 
method must have a void return 
type, but don’t forget your basic 
java rules: just because you see a 
return statement: return; does 
not mean you^re returning a value. 
Don’t be fooled by considering 
anything other than the actual 
declared return type of the 
ejbCreateQ method. 


Only ONE client can access 
a session bean at a time ， 
regardless of whether the bean 
is stateless or stateful! 

S=5=5S ： 

the clients through one at a time. container 

-P 

y-Cw ZZ a sinZou 

Z7Z%TcTn'tLn JSE — 一 

bean like synchronized, wait, notify, etc.) 
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i^^rpen your pencil 


Who does What? 


From the list of words below, arrange them in the appropriate lists according to 
whether it’s a responsibility of the Bean Provider, the Container, or the Client. 


creating the Home object class implementing the SessionContext class 

invoking setSessionContextO 

invoking ejbCreateO invoking ejbRemoveO 

implementing the EJBObject class creating the home interface 

implementing the Handle class invoking create() 

implementing SessionBean 

invoking a business method 

on the component interface implementing the create() method 

implementing the ejbCreateO method implementing the ejbActivate() method 

invoking ebjPassivateO 
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session context 


SessionContext 

You need it more thaw it needs ^ou 

At the beginning of a bean’s life, and only once in the bean’s life, the 
Container calls the bean’s setSessionContext() container callback method. 

That context (a subclass of EJBContext) is the bean’s lifeline to the Container, 
and it’s the only thing the bean can call methods on to get references to his 
own home and EJB object, to get security information about the client, or to 
do transaction-related things. We won’t look at the security and transaction 
info now; they’re both covered in separate chapters. 


You are SO frickin 1 lucky to have me. I’m 
as close as you'll ever get to the Container, 
baby, so you better take good care of me. And 
you only get one shot at it—if you don't save me when 
the Container calls setSessionContextO, you're 
screwed. And don’t do anything stupid like null out 
my reference. Sooner or later, you're gonna 
need me for something. 


Um, let's get this straight- 
youre here to serve ME. So you better 
get used to hearing, u Oh Context Boy, get 
me a transaction .〃 u Oh Context Boy, get me 
the client’s security info" And I almost 
forgot, I take one sugar and no cream 
in my coffee. 

o x 



SessionContext 


Bean 


Memorize the 

SessionContext 

interface! 

You must be able to look at a list of 
methods, and know which belong to the 
SessionContext interface. And remember, 
a lot of the questions related to lifecycle 
are about knowing the methods from which 
you can call certain methods on your 
context For example, you have to know 
that you can ! t get client-related mfo from 
your context in the ejbCreate() method 
of a stateless bean. Because there s no 
client associated with a stateless bean s 
ejbCreateO! But you CAN get client mfo 
from your context from a stateful bean s 
ejbCreateQ, because a client initiated it. 
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Things you can do with your SessionContext 

(9 methods，4 categories) 


愈 

home ref 


■ get a reference to your home 

getE JBHome () 
getEJBLocalHome() 


e 



EJB object ref 


get a reference to your EJB object 

getEJBObject() 
getEJBLocalObject() 


k ■ 

client security 


get security information about the client 

getCallerPrincipal() 
isCallerlnRole(String s) 



_ f orce a transaction to rollback (CMT only) 

CXj setRollbackOnly (boolean b) 

transactions 

■ find out if the transaction has already been 
set to rollback (CMT only) 

getRollbackOnly() 

■ get a transaction reference, and start your 
own transaction (BMT only) 

getUserTransaction() 


O 

O 


you don’t need 
to know the three 
deprecated methods. 

Besides the ones shown on this page, 
the EJBContext interface has three 
other methods, all of which have 
been deprecated. You’re not tested 
on deprecated methods, so if you see 
them in the API, don’t panic. The only 
reason you need to know about them 
is in case you’re working with older 
EJB code. The methods are: 

isCallerlnRole(ldentity id) 

getCallerldentity() 

getEnvironment() 
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Tikibean Lounge 



Stateless bean: I don't see how you can stand 
it, being a stateful bean. Your whole life is tied to 
servicing one client. 

Stateful bean: I'm not sure I like the way you phrase 
that, ''servicing one client”. Makes it sound like I'm a 
personal slave, or something. 

Stateless bean: And that would be wrong because... 

Stateful bean: Ifs a personal, intimate relationship. A 
relationship that you couldn’t possibly comprehend. 

Stateless bean: What is THAT supposed to mean? 

Stateful bean: Because your relationships are so... 
transient. You don’t really care WHO you service. Any 
client in a storm, as they say. 

Stateless bean: Theres nothing wrong with that. I’m 
a people person. I like being in the pool with the other 
beans, then constantly meeting new clients. Ifs never 
boring, and I barely ever see the same client twice 
and— 

Stateful bean: My point exactly! Youre not even 
PHYSICALLY able to sustain a meaningful, ongoing 
relationship. 

Stateless bean: Excuse me? 

Stateful bean: Ifs that short-term memory loss 
thing. You can’t hold any client information between 
method calls, which is why it doesn’t matter WHICH 
client calls. Youd never be able to remember even if you 
got the same client calling ten of your methods in a row. 

Stateless bean: Yeah, but that’s not a problem. 
Remember, I'm used for services that don’t NEED me 
to remember anything from clients between method 
calls. 


Stateful bean: Which is also why youre not used for 
anything big or serious. 

Stateless bean: Now wait just a minute here—that is 
SO not true! In fact, if you want to talk performance, 
buddy, I’m way more scalable than you. And before 
you start arguing, don't even give me that nonsense 
about passivation. Ive heard all the arguments. But 
passivation will NEVER make you as scalable as me. 

Stateful bean: OK, maybe I'm not quite AS scalable... 
but there are more important things in life to consider. 

Stateless bean: For example? 

Stateful bean: Well, I'm easy to use. Easy and quick 
to build. Maybe that’s more important to the developer. 
And in some cases, I’m still gonna perform better, when 
you really do need client conversational state. The 
options can really suck sometimes... having to store 
the state in a database with each call (and then go and 
look it all up again with the very NEXT call)? I know 
sometimes you have to do that, but still. Or, sure, you 
could just keep sending the conversational state back to 
the client so that they can turn around and send it back 
to YOU with each call and— 

Stateless bean: Whafs wrong with that? 

Stateful bean: Here's a new word for your 
vocabulary... ''bandwidth". Pronounce it with me... 
、 'baaandwiiiidth”. Do you really want all that going back 
and forth? 

Stateless bean: Ok, yeah, got it. But tell me, how 
is this worse for performance than the hit from 
passivation/activation? And while were at it—wait, did 
you hear that? I think I hear your client calling. And 
it sound like... no... wait... yes... I’m afraid it sounds like 
he's calling remove(). Ifs been nice talking to you. HI 
be thinking about you while I’m out at the pool. Floating 
on air mattress. Getting a tan. Drinking margaritas with 
shaved ice. Wow. I LOVE being me. 
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session bean lifecycle 

Put a check next to the methods that you can call on your SessionContext, if it's allowed from the 
methods in the left column. For example, in ejbCreate() you can get a reference to your home for both 
stateless and stateful session beans, so you can put a check in the top box in both columns. All of the 
answers are in this chapter, but try to make your best guess before going back for the answers. You 
might want to make another one of these yourself, to include JNDI, resource, and bean access. 


Bean methods Stateful 


Stateless 


ejbCreate 

ejbRemove 

Use your SessionContext to: 

□ get a reference to your home 

□ get a reference to your EJB object 

□ get security information about the client 

□ force a transaction to rollback (CMT 
beans) 

□ find out if the transaction has already 
been set to rollback (CMT beans) 

□ get a transaction reference, and call 
methods on it (BMT beans) 

Use your SessionContext to: 

□ get a reference to your home 

□ get a reference to your EJB object 

□ get security information about the client 

□ force a transaction to rollback (CMT 
beans) 

□ find out if the transaction has already 
been set to rollback (CMT beans) 

□ get a transaction reference, and call 
methods on it (BMT beans) 

ejbPassivate 

ejbActivate 

Use your SessionContext to: 

□ get a reference to your home 

□ get a reference to your EJB object 

□ get security information about the client 

□ force a transaction to rollback (CMT 
beans) 

□ find out if the transaction has already 
been set to rollback (CMT beans) 

□ get a transaction reference, and call 
methods on it (BMT beans) 

Does not apply: 
stateless beans are 
never passivated. 

business 

methods 

Use your SessionContext to: 

□ get a reference to your home 

□ get a reference to your EJB object 

□ get security information about the client 

□ force a transaction to rollback (CMT 
beans) 

□ find out if the transaction has already 
been set to rollback (CMT beans) 

□ get a transaction reference, and call 
methods on it (BMT beans) 

Use your SessionContext to: 

□ get a reference to your home 

□ get a reference to your EJB object 

□ get security information about the client 

□ force a transaction to rollback (CMT 
beans) 

□ find out if the transaction has already 
been set to rollback (CMT beans) 

□ get a transaction reference, and call 
methods on it (BMT beans) 
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"TJicck Sxom 



Which statements about session beans are true? (Choose all that apply.) 

Q A. A stateful session bean is typically used to represent a row in a database 

口 B. The client must call the ejbActivate method before calling any business 
methods. 

口 C. A stateful session bean’s fields can contain client conversational state. 
Q D. They are typically used as asynchronous message consumers. 


Which list(s) correctly sequence some of the steps in a session bean’s lifecycle? 
(Choose all that apply.) 

□A. ejbCreate (), newlnstance(), setSessionContext() 

□ B. newlnstance (), setSessionContext (), ejbCreate() 

□ C. ejbCreate (), setSessionContext (), newlnstance() 

□ D. newlnstance (), ejbCreate(), setSessionContext(). 

□ E. setSessionContext (), newlnstance (), ejbCreate() 


Which types of session bean instance fields can be successfully passivated and 
reactivated? (Choose all that apply.) 

Q A. A reference to the remote home interface. 

口 B. A reference to the UserTransaction interface 
Q C. A reference to a database cursor. 

Q D. A reference to the SessionContext object. 

Q E. A reference to a socket. 
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4 


Which are valid remote component interfaces for a session bean? (Choose all 
that apply.) 


□A. public interface MyBean extends javax.ejb.EJBObject { 
void myMethod(); 

} 

□ B. public interface MyBean extends javax.ejb.EJBObject 
throws RemoteException { 

void myMethod(); 

} 

口 C. public interface MyBean extends 
javax.ejb.EJBHomeObject { 

void myMethod() throws RemoteException; 


□ D. public interface MyBean extends javax.ejb.EJBObject { 
void myMethod() throws RemoteException; 


If a client makes a call to a session object that has been removed by the 
container, which exceptions can be thrown? (Choose all that apply.) 

Q A. j ava • rmi. RemoteException 
Q B. j avax. ejb. RemoveException 

□ C. java. rmi .NoSuchObjectException 
口 D. javax• ejb.NoSuchEntityException 

□ E. javax. ejb.ObjectNotFoundException 

Given: 

15. MyBean create(String name) throws CreateException r 
RemoteException; 

Which session bean interface can contain this method? 

口 A. Only stateful session beans 
Q B. Only stateless session beans 
口 C. Both stateful and stateless session beans 
口 D. Neither stateful nor stateless session beans 
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What is true about a session bean’s lifecycle? (Choose all that apply.) 

口 A. If a business method throws a system exception the bean will be 
passivated. 

Q B. A passivated bean must be activated before it can be removed. 

口 C. A stateless session bean’s removal must be initiated by the client not the 
container. 

口 D. Stateless session beans cannot implement the SessionSynchronization 
interface. 



Which are required of the bean provider to ensure that a session bean is 
successfully passivated? (Choose all that apply.) 

Q A. The provider must call ejbPassivate (). 

Q B. The provider must always add business logic to the ejbPassivate () 
method, if the bean is stateful. 

[I C. The provider must close any database connections before 

ejbPassivate () completes. 

Q D. The provider must assume that any state stored in instance fields marked 
transient will be lost. 

Q E. The provider must assume that any reference to the SessionContext 

object will be not survive passivation if the SessionContext object is not 
serializable. 


Given a stateless session bean with container-managed transaction 
demarcation, from which method(s) can you access another bean? (Choose 
all that apply.) 

□ A. ejbCreate () 

□ B. ejbRemove () 

口 C. a business method 

□ D. setSessionContext() 
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(Note: The real exam has several types of ‘drag and drop’ questions, that 
we’re going to do a lame job of simulating with this question...) 


Match the methods on the left with the interfaces in which those methods 


can be found, on the right. A match is correct if the method is either declared 
in, or inherited by, the interface. Note: There may be some many-to-one and 
one-to-many relationships in your answer. 


A. afterCompletion 

B. getUserTransaction 

C. afterBegin 

D. isCallerlnRole 


1. SessionSynchronization 

2. SessionContext 

3. SessionBean 

4. UserTransaction 


E. getRollBackOnly 

F. setSessionContext 

G. setRollbackOnly 


What is true about a session bean’s lifecycle? (Choose all that apply.) 

Q A. The container will always create a new session bean instance when 

the client invokes the create () method on the home interface of a 
stateless bean. 

Q B. The container will always call ejbRemove () when the client invokes 
the remove () method on a stateless bean’s home interface. 

口 C. A session bean cannot be passivated while it is in a transaction. 

Q D. The setSessionContext () method is not invoked during a stateless 
bean’s lifecycle 

Which of the following methods are container callback methods? (Choose all 

that apply.) 

□ A. ejbPassivate () 

□ B. setRollbackOnly() 

□ C. setSessionContext () 

□ D. getRollbackOnly() 

□ E. getUserTransaction() 
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In what case(s) will the container fail to call ejbRemove() on a session bean? 
(Choose all that apply.) 

口 A. If the container crashes. 

Q B. If an application exception is thrown from a business method. 

口 C. If a timeout occurs while the bean is in the method ready state. 

[1 D. If an application exception is thrown from within a transaction. 


H 


Which method (s) allow both stateful and stateless session beans with bean- 
managed transaction demarcation to access UserTransaction methods? 
(Choose all that apply.) 

□ A. ejbCreate () 

□ B. ejbRemove () 

口 C. a business method 

□ D. setSessionContext() 


15 


For which type of bean can the container passivate an instance that is in a 
transaction? 


Q A. only stateful session beans 
Q B. only stateless session beans 
口 C. both stateful and stateless session beans 
Q D. neither stateful nor stateless session beans 


16 


For session beans, which are the responsibility of the Container? (Choose all 
that apply.) 

Q A. Invoking the local interface create () method. 

□ B. Invoking the getSessionContext () method. 

口 C. Invoking the ejbCreate () method. 

Q D. Ensuring that the ejbRemove () method is always invoked. 
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For this drag and drop type question, you can use each element only once. 
Which interface should be matched with which fact, so that all four matches 
are correct? 


1. remote component 

2. remote home 

3. local component 

4. local home 


a. Has a getHomeHandle () method 

b. extends ' javax.ejb.EJBObject^ 

c. methods must NOT throw 

' j ava. rmi. Remo teExcept ion ' 

d. can be used to retrieve an ETBLocalObject 


Which can be called by the container during the lifecycle of a session bean? 
(Choose all that apply.) 

□A. create() 

Q B. bean constructor 

□ C. setRollbackOnly () 

□ D. getUserTransaction() 

□ E. ejbRemove () 

Which statements about a session bean class are true? (Choose all that apply.) 
口 A. They can be marked ‘final’ 

Q B. They do not need a no-argument constructor. 

口 C. Their component interface methods can be ‘private’. 

Q D. Their business method names must start with “ejb”. 

Q E. Their ‘ejbCreate’ methods must not be declared as ‘final’. 

For which type of bean can the SessionSynchronization interface be 
implemented? 

Q A. only stateful session beans 
Q B. only stateless session beans 
口 C. both stateful and stateless session beans 
Q D. neither stateful nor stateless session beans 
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Which statements are true for stateless session bean instances? (Choose all 
that apply.) 


Q A. Any instance can be used for any client. 

Q B. Conversational state must be retained across methods 
口 C. Conversational state must be retained across transactions. 
Q D. They can be passivated. 

口 E. They do not support transactions. 
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TJtoc^ Sxom 

_ (s^c6: 刀 I) 

Which statements about session beans are true? (Choose all that apply.) 

U A. A stateful session bean is typically used to represent a row in a database ^ , 

Q B. The client must call the ejbActivate method before calling any business - o^ly -tV>c tontdmev tails 
methods. cjbA^t ,v/ 3*tcO 

C. A stateful session bean’s fields can contain client conversational state. 

Q D. They are typically used as asynchronous message consumers. 


Which list(s) correctly sequence some of the steps in a session bean’s lifecycle? 
(Choose all that apply.) 

□A. ejbCreate(), newlnstance(), setSessionContext() 

^ B. newlnstance(), setSessionContext(), ejbCreate() 

□ C. ejbCreate() A setSessionContext(), newlnstance() 

□ D. newlnstance(), ejbCreate(), setSessionContext(). 

□ E. setSessionContext(), newlnstance(), ejbCreate() 




Which types of session bean instance fields can be successfully passivated and 
reactivated? (Choose all that apply.) 




A. A reference to the remote home interface. 

B. A reference to the UserTransaction interface 




Q C. A reference to a database cursor. - vcw 
^ D. A reference to the SessionContext object. 
Q E. A reference to a socket. - 


?asswaW 匕 o' 


u ld V>c s—aVwW 


代咖加 bw passivaiio, dould be s C Hali^ io , 
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Which are valid remote component interfaces for a session bean? (Choose all 
that apply.) 

□ A. public interface MyBean extends j avax.ejb.EJBObject { 
void myMethod() ; - 




ioh 


□ 


B. public interface MyBean extends j avax.ejb.EJBObj ect 
throws RemoteException { 

void myMethod(); 


illegal Java ! 


□ 




C. public interface MyBean extends 
javax.ejb.EJBHomeObject { 

void myMethod() throws RemoteException; 


be 




D. public interface MyBean extends j avax.ejb.EJBObject { 
void myMethod() throws RemoteException; 


If a client makes a call to a session object that has been removed by the 
container, which exceptions can be thrown? (Choose all that apply.) 

A. java. rmi.RemoteException 

n UWr.s or. 

Q B. javax. ejb.RemoveException -* '' 

^ C. java. rmi.NoSuchObjectException 卜 

Q D. javax.ejb.NoSuchEntityException - dor\*b sc 

□ E. j avax. e jb. Ob j ectNotFoundException - ^is is (oy Chtity 

Given: 

MyBean create(String name) throws CreateException , 
RemoteException; 

Which session bean interface can contain this method? 

A. Only stateful session beans 
Q B. Only stateless session beans 
口 C. Both stateful and stateless session beans 
口 D. Neither stateful nor stateless session beans 






.s-t 
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What is true about a session bean’s lifecycle? (Choose all that apply.) 

口 A. If a business method throws a system exception the bean will be 
passivated. 


(s ? e6 ： n ^ 


⑽如 V ) 咖 


\s V\WtA 


Q B. A passivated bean must be activated before it can be removed. 


Q C. A stateless session bean’s removal must be initiated by the client not the 
container. 

^ D. Stateless session beans cannot implement the SessionSynchronization 
interface. 


Which are required of the bean provider to ensure that a session bean is 
successfully passivated? (Choose all that apply.) 

Q A. The provider must call ejbPassivate (). 

Q B. The provider must always add business logic to the ejbPassivate () 
method, if the bean is stateful. 

The provider must not close any database connections before 

ejbPassivate () completes. 

The provider must assume that any state stored in instance fields marked 
transient will be lost. 

口 E. The provider must assume that any reference to the SessionContext 

object will be not survive passivation if the SessionContext object is not 

serializable. 匕山.… 饮 娜 ST pass i va ^ youv wte 此⑽ maticv v/hat! 


□ C. 

〆 D. 


Given a stateless session bean with container-managed transaction 
demarcation, from which method(s) can you access another bean? (Choose 
all that apply.) 

□A. ejbCreate() 

□ B. e jbRemove () 

^ C. a business method ** a,so ^ ^ BMT bca ⑽ 

□ D. setSessionContext() 


( s _: 11-扣 




you are here ► 253 





mock exam answers 


10 


(Note: The real exam has several types of ‘drag and drop’ questions, that 
we’re going to do a lame job of simulating with this question...) 

Match the methods on the left with the interfaces in which those methods 
can be found, on the right. A match is correct if the method is either declared 
in, or inherited by, the interface. Note: There may be some many-to-one and 
one-to-many relationships in your answer. 


(API dots) 


A. afterCompletion I 

B. getUserTransaction X 

C. afterBegin I 

D. isCallerlnRole 2- 

E. getRollBackOnly 2- 

F. setSessionContext ^ 

G. setRollbackOnly 2 •，千 


1. SessionSynchronization 

2. SessionContext 

3. SessionBean 

4. UserTransaction 


11 


What is true about a session bean’s lifecycle? (Choose all that apply.) 

Q A. The container will always create a new session bean instance when 

the client invokes the create () method on the home interface of a 
stateless bean •一 makes stateless bedv\s ii vjSy\is 


(s^: I。) 


Q B. The container will always call ejbRemove () when the client invokes _ Coh"t5ihev verwoves 
the remove () method on a stateless bean’s home interface. s-ta-tclcss be3h OHLY 

C. A session bean cannot be passivated while it is in a transaction. 如 : s shvihk 

[I D. The setSessionContext () method is not invoked during a stateless 
bean’s lifecycle 


n 


Which of the following methods are container callback methods? 
that apply.) 


W A. 

□ B. 

c 

□ D. 

□ E. 


ejbPassivate() 
setRollbackOnly() 
setSessionContext() 
getRollbackOnly() 
getUserTransaction() 


(Choose all 


(s^c6 - 
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In what case(s) will the container fail to call ejbRemove() on a session bean? 
(Choose all that apply.) 

^ A. If the container crashes. 

口 B. If an application exception is thrown from a business method. 

口 C. If a timeout occurs while the bean is in the method ready state. 

口 D. If an application exception is thrown from within a transaction. 


Which method (s) allow both stateful and stateless session beans with bean- 
managed transaction demarcation to access UserTransaction methods? 
(Choose all that apply.) 

□ A. ejbCreate()^ ^ o^7 

□ B. e jbRemove () 

C. a business method 

□ D. setSessionContext() 


(sp6 H) 




For which type of bean can the container passivate an instance that is in a 
transaction? 


口 A. only stateful session beans 
Q B. only stateless session beans 
Q C. both stateful and stateless session beans 
zT D. neither stateful nor stateless session beans 


(s^: I。) 


For session beans, which are the responsibility of the Container? (Choose all 
that apply.) 

口 A. Invoking the local interface create () method. - 乇 

Q B. Invoking the getSessionContext () method. - Co^-ta'mcv- tails sc*tScssioy>Co^-tc^*t 
^ C. Invoking the e jbCreate () method. 

口 D. Ensuring that the e jbRemove () method is always invoked. - / i 

,? V bc hissed i-f 

, ^icd * 十 


L ^ed oui 


cx 


^p-ti 


ion 


>WS 3 


Olr 
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For this drag and drop type question, you can use each element only once. 
Which interface should be matched with which fact, so that all four matches 


are correct? 

1. remote component b 

2. remote home a 

3. local component t 

4. local home A 


a. Has a getHomeHandle () method 

b. extends ' javax.ejb.EJBObject' 

c. methods must NOT throw 

' j ava • rmi. Remo teExcept ion ' 

d. can be used to retrieve an EJBLocalObject 


18 


Which can be called by the container during the lifecycle of a session bean? 
(Choose all that apply.) 

Q A. create () 一 

^ B. bean constructor 

□ C. setRollbackOnly () . (! . 

一 btav\ ddlls these 

□ D. getUserTransaction() 

3 E. e jbRemove () 




19 


Which statements about a session bean class are true? (Choose all that apply.) 
Q A. They can be marked ‘final’ 

Q B. They do not need a no-argument constructor. 

口 C. Their component interface methods can be ‘private’. 

[I D. Their business method names must start with “ejb”. 

^ E. Their ‘ejbCreate’ methods must not be declared as ‘final’. 




ZO 


For which type of bean can the SessionSynchronization interface be 
implemented? 


^ A. only stateful session beans 


Q B. only stateless session beans 
口 C. both stateful and stateless session beans 
[I D. neither stateful nor stateless session beans 


(s_: "1 弓 ) 
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Which statements are true for stateless session bean instances? (Choose all 
that apply.) 

8^ A. Any instance can be used for any client. 

Q B. Conversational state must be retained across methods 
Q C. Conversational state must be retained across transactions. 

Q D. They can be passivated. 

Q E. They do not support transactions. 


(s_: 
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Entity beans persist. Entity beans exist. Entity beans are. They are object 
representations of something in an underlying persistent store. (Think: database, 
because most entity beans represent something from a relational database.) If you 
have a Customer entity bean, then one bean might represent the entity Tyler Durden, 

ID #343, while another is the entity Donny Darko, ID #42. Two beans, representing two 
real entities. An entity bean is simply a realization of something that already exists in a 
persistent store. Something that already is. And these suckers are hard to kill! As long as 
the data is in the database, it can keep coming back in the form of an entity bean. 


♦ 


Entities are Persistent 


广 ...and then I said, You want a piece 
of me? Go ahead — take your best shot buddy!" 

He didn’t know he was messing with an entity bean. So 
he threw an exception, then he crashed the server, 1 
but I*m still here! I won’t go down that easy, no 
v siree. As long as I'm in the database, I'll just 
keep coming back, so do your worst! 


this is a new chapter 
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5-1 Identify correct and incorrect statements or 
examples about the client view of an entity 
bean’s local and Remote home interface, 
including the code used to locate an entity 
bean’s home interface, and the home 
interface methods provided to the client. 


5.2 Identify correct and incorrect statements 

5.3 or examples about the client view of an 
entity bean’s local component interface 
(EJBLocalObject) and Remote component 
interface (EJBObject) 

5.4 Identify the use, syntax, and behavior of the 
following entity bean home method types 
for CMP: finder methods, create methods, 
remove methods, and home business 
methods. 
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Ct mecuui: 

You have to know the rules for an entity bean home 
interface, and especially how they’re different from a 
session bean. You must know that you’re not required 
to have a create() method, but that you must have 
at least one finder method, findByPrimaryKey(). You 
have to know that the return type of single-entity 
finders and create methods must always be the 
component interface type, but that multi-entity finders 
must return a Collection. You must know that single¬ 
entity finders throw an ObjectNotFoundException if 
there’s no match in the database, but that multi-entity 
finders always return a Collection, even if its empty. 
You also have to know that home business methods 
aren’t required to return the component interface — 
they can return anything that can be legally passed. 
You must also know that if an entity is deleted from the 
database, it can no longer be represented as an entity 
bean, but that if an entity bean instance dies (through 
an exception or even a server crash), the entity itself 
persists. As long as the entity is in the database, it can 
be represented by an entity bean. 

The rules for how you define things in an entity 
component interface are identical to the rules for a 
session bean component interface. But in objective 
5.4, we’ll look at how the methods behave differently. 

The behavior of remove() is profoundly different for 
an entity bean, and you must understand that calling 
remove() really means, “delete this entity from the 
underlying persistent store!” You must know that 
calling create() on an entity bean means, “insert a 
new row in the database” (OK, technically it means, 
“create a new entity in the underlying persistent store.”) 
You must know that if an entity is deleted from the 
underlying persistent store, the entity bean ‘dies’，even 
though the bean instance goes back to the pool. 
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Whafs aw cwtity bcaw? 


CUSTOMER TABLE 


Last 

First 

ID 

Darko 

Donny 

42 / 

Jones 

Indie 

343 

一 ■一 

Lin 

Tam 

100 


I m a \>cvs\stcvv*t stove, 
t 构一外⑽七“士- 

e ㈣ 扣‘加 

w a\>s *to ovvC 代叫’.） 


Last ： Dark 。 
First ： Donny 
ID ： 42 

^^omer 


Last ： Jones 
First ： Indie 
ID ： 343 

^s'fomer 


Last ： Lin 
First ： Tam 
ID ： 100 

^s^o/ner 洛❼。 


An entity bean is an object-oriented way of looking at in a persistent store. The spec 
says “persistent store’’，and doesn’t specify what that persistent store must be. It could 
be anything that satisfies the requirements of ‘persistence’ including a relational 
database, an object database, or even something as lame and inefficient as storing 
serialized objects to files. But in most real-world scenarios, we’re talking a relational 
database. And that means an individual row in a table maps to a unique entity bean. 
The object-to-relational (OR) mapping could be a lot more complex than a simple one 
row equals one bean scenario, but we’ll get into that in the next chapter. 

Entity beans are data objects. They are...things. Nouns. As opposed to session beans 
which are processes. Verbs. Entity beans might represent things like people, products, 
orders, bookings, inventory, animals...Entity beans would not represent 
things like credit card verification, advisor service, order submission, membership 
registration... processes. 

Of course, in virtually all well-designed EJB applications, entity beans will be combined 
with session beans, where the client interacts with the process session bean, and the 
session bean uses entity beans when it needs data as part of the process. 
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Entities vs. Entity Peaws 

An entity is the real thing that the entity bean represents. 
It doesn’t work in reverse! The entity does not represent 
the entity bean. That might seem like a subtle point, but 
it’s not. The difference is in knowing which one is real ， 
and which one is simply a view of the real thing. 

In other words, if you delete the real entity (the thing) 
in the database, the entity bean disintegrates. Poof. But 
if the entity bean dies, as an instance on the heap, it 
doesn’t kill the real entity in the database. (By the way, 
we’re now going to say ‘database’ instead of ‘underlying 
persistent store’，but you and I both know that these two 
are not necessarily synonymous, and that the ‘underlying 
persistent store’ need not be —— but usually is — a database. 
There, we’ve said it.) 

So you won’t have the right perspective if you think of 
the entity bean as some data object that happens to be 
backed up to persistent storage. In nearly all applications, 
the vast majority of entities used in the app are not 
realized as entity beans at any given time. Instead, most 
entity beans become a representation of an underlying 
entity only when that particular entity is needed in the 
application logic. 

For example, imagine your database has 10,000 
customers. But at any given time, clients (through 
business processes in session beans) are using only 200 
of those customers. In that case, you probably have only 
200 entity beans actively representing customer entities. 
The rest of the 9,800 customer entities are just sitting 
there in the database, waiting for a client process to 
need them. 

Think of entity beans as actors. In the scenario we just 
described, you have 200 actors, each playing a different 
role of someone in the database. But the other 9,800 
entities in the database — the other customers — do not 
have anyone playing them. 


But as soon as a client comes along and tries to get one 
of those other 9,800, say, to change that customer’s 
address, or check its credit limit, an actor (entity bean) 
will be chosen to play the role of that selected customer. 
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fjiereiareaiP 

Dumb Questions 


Just so I’ve got this straight 
your entire database doesn’t get 
loaded in as entity beans, right? I 
mean, that would be insane. 


Entity beans are an 00 way of 
looking at data in a persistent store. 


A- 

You’re right, at least about the 
first part. No, your entire database 
is NOT loaded in as entity beans. 

Think of entity beans as just-in-time 
representations of only the entities in 
the database that are actively needed 
by client business processes. 

But does that mean it would be insane 
to load them all in? Not necessarily. 
While it would certainly up your 
resource requirements, especially if 
the data in the underlying database 
continues to grow, just think of how 
FAST it would be. 

Although there is nothing in the 
spec that requires this, a vendor can 
choose to let you configure the app 
in such a way that it does pre-load 
all the entities in the database into 
beans.That gives you, essentially, a 
lightening-fast in-memory database, 
that still synchronizes itself with the 
real underlying store (you’ll see how in 
a moment). 

And to take it a step further, if your 
server gives you a way to tell it that 
your entity beans are your only access 
to the database, then the server can 
even eliminate the synchronization 
and just keep the database in memory, 
saving only what it needs as a backup 
in case of a crash. 


An entity is a real, uni^iely - 
identifiable tiling ftat exists 
Somewhere outside of EjB, and 
fte entity bean’s job is Simply to 
BECOME an 00 viewofftat real, 
persistent entity. 

The entity bean cannot exist 
wifliout Ae real entity, but Ae real 
entity can exist wiftout fte bean. 

An entity bean is NOT Ae real 
entity -- if S just a representation or 
“realization” of Ae entity. 
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^JiereiareriP 

Dumb Questions 


Why do you even NEED entity beans? Why 
not just go straight to the database from a session 
bean? 


A ： 


You can go from a session bean directly to the 
database. Heck, you can always go from the client to 
the database, but then we’re back to the old non- 
scalable client-server two-tier architecture, and we 
all know why that is usually a bad idea (doesn’t scale, 
business logic is in the client, hard to maintain, etc.) 

If you use entity beans instead of direct calls to 
the database, you get to take advantage of all the 
Container’s services, including the ability to wrap 
several database trips in one transaction. But as you’ll 
see, one of the biggest benefits of using entity beans 
is that the Container automatically synchronizes 
between the database and the entity bean. 

But the single most compelling reason for entity 
beans is that they take you from the relational world 
to the object world. In other words, you get to stay 
with objects all the way down, in your app, rather 
than mapping back and forth in your code. And if 
you’re using CMP, which you almost certainly will be 
(for reasons that will become obvious a little later), 
you won’t have a shred of SQL in your bean code. In 
fact, with CMP entity beans, you get to pretend that 
your entire database exists solely as objects on the 
heap. 

Sure, maybe you’re comfortable with JDBC, but what 
about the rest of the team? And let’s face it — think¬ 
ing in 00 makes a lot more sense than having to 
shift between 00 and entity code. 


「鱗二 

to know 


We „Jort h e T t ㈡ 。 二：巧 ^ 

SQL itseK 二 = kn0W tha t a bean 

the bean ^fJJ^taSource lookups -n 
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Ewtity beans from the clicwfs poiwt of view 


entity bean intro 


With the customer bean, I want to 
input new customers, remove customers, 
and update customer information. I also 
want to do queries—to select customers 
based on some criteria. And I’m sorry, but 
I just REFUSE to think in SQL. You know 
what they say... once you've tried an 
object, you'll never go back... 


% 



The client wants to do database 
stuff, but in a Java OO way. 


■ 


■ 


■ 


■ 


Make a new entity (an SQL INSERT) 

Delete an entity (an SQL DELETE) 

Update entity state (an SQL UPDATE) 
Search/query on entities (an SQL SELECT) 


The client interface for an entity bean is a 
little different from that of a session bean. For 
example, when a session bean client wants to 
get a bean, so that it can call the bean’s business 
methods, the client calls create () and the 
Container allocates a new EJB object. 


But what if a client wants to use an existing entity 
bean? For example, what if the client doesn’t 
want just some random entity, but wants the EJB 
object of a specific entity, say, Bart Simpson # 12? 

In that case, a create () won’t work. The client 
doesn’t want a new entity, but wants a reference to 
an existing entity. So as you’ll see in a minute, the 
client interface for an entity bean adds (and must 
have) one or more finder methods. 


The next two pages are high-level pictures of 
how entity beans are created (insert), and found 
(select). The scenarios in these pictures will be 
filled in with a lot more detail as we go through 
this chapter, but for now you can relax. 
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entity beans 




EJB 




Entity bean overview 

Scenario: client wants a reference to an existing entity 


1 After doing a JNDI lookup on the entity bean home and getting a home interface reference, 
the client calls findByPrimaryKey (“ 27”) on the home stub. 

2 The findByPrimaryKey (“ 27”）method invocation is passed to the home object. 

3 The Container asks a bean in the pool to verify that #27 exists in the database. 


1 The bean checks for an entity in the database with primary key #27 


2 The bean tells the home that #27 is in the database 


3 The Container makes or finds an EJB object for #27 (there might already be one) 

4 The Container returns the stub for #27 


context 


bean 1 
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Entity bean overview 

Scenario: client wants to create a new entity 



W'W ■一 



1 After doing a JNDI lookup on the entity bean home and getting a home interface reference, 
the client calls createfBilly Bob”）on the home stub. 

2 The createfBitly Bob”) method invocation is passed to the home object. 

3 The Container pulls a bean from the pool for this bean type (could be any random bean in the 
pool). Notice that the bean already has its own context that sticks with the bean. 



generates a new primary key. 

2 The bean is linked to an EJB object, and both the context and EJB object get the new primary key. 

3 The Container returns a stub for the newly-created entity (Billy Bob, #55). If the client’s only 
goal was to insert the new row, the client might not even care about the returned stub. 
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Customer entity bean 


A very simple Customer entity bean 

// package and inports here 

public class CustomerBean implements EntityBean { 

private String lastName; 丁 ^ 扯 ， s s Ue St 

private String firstName; 1 C usW'f 广 

private String primaryKey; ) ^ awC , last a^d IP ( ? r,wa，r V KC V ， 

private EntityContext context; ^.v/o^ ，S * ^cad'^f^ scss^o^ca^ C ^ 

public String ejbCreate(String last. String first) { 
lastName = last; 


firstName = first; 
primaryKey = this.getPK(); 
// DB INSERT 
return primaryKey; 


public String getLastName() { 
return lastName; 

} 

public void setLastName(String name) 
lastName = name; 

} 

public String getFirstName() { 
return lastName; 

} 

public void setFirstName(String name) 
firstName = name; 


public void ejbActivate() { } 
public void ejbPassivate() { } 
public void ejbRemove() {// DELETE 


Po^t tw,s look a 


T\^t c\b( 
rt v\o>w 


ahd 遊 


mca^my, as you II sec laW m tK.s 


public void setEntityContext(EntityContext ctx) { 
context = ctx; 

} 


public void unsetEntityContext() { } 
public void ejbLoad() {// SELECT } 
public void ejbStore() {// UPDATE } 


: xt c 二 ) . u kc S ctScss«o^Co^t 

藏㈡ 二二 


wsort 


仏 w to^ tY tMatks 4or, -the 匕 

— ih —. Th — ，二離如 

+ Unt) (Math. random () * 42) ; World's y/ovs 七 f\rimavy key alfrtWl^nr^ly _ d use tlicmx- 

SU 汗 lied rn*fo o\r Uc daiabasc s au-fco-y^cratcd key. 


private String getPK() { 
return、、" 

} 


(igy\o\rc *t^csc last buo 

public String ejbFindPrimaryKey(String pk) {// SELECT, return pk } i^ods -fov y\o>w) 

public Collection ejbFindByCity(String city) {// SELECT, return collection of keys } 
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Aw cwtity beaw's clicwt view 

Our Customer bean isn’t finished, so don’t get too attached to it! And in fact, the code 
is an example of bean-managed persistence (BMP) which we really won’t be using in this 
book. We’ll talk a little about BMP, and a lot about its much more popular counterpart — 
contom^r-managed persistence (CMP) in this chapter and the next. For now though, we’ll 
focus on the client view of an entity bean, and this simple bean is just to get you started 
looking at entity bean code. 

Given that a Customer bean represents a Customer entity (i.e. a real customer) in the 
underlying database, what behaviors should the entity bean have? In other words, what 
kinds of things might the client want to do with either a single Customer or multiple 
Customers? 

Things you’d do with a database record! The things we mentioned earlier including 
make a new Customer, delete a Customer, update a Customer’s fields (columns), and 
query/search on the Customer database. 





Think about the following operations, and figure out which of 
the two client interfaces (component or home), is better suited 
for each operation. Keep in mind that the rules for entity bean 
interfaces might be different from session bean interfaces. If 
you think both interfaces are appropriate, check them both. 
(We’ve done the first one for you.) 


package ^ 

headfirst 

/ ^ption; 


package 
headfirst; — 


rmi.RemoteEx 


home component 


Make a new customer 


package 
headfirst; ~ 


package \ > 
headfirst; _ 

inport: 

javax.ejb.*; 


inport 
javax.ejb.*; 

rmi.RemoteEx 
ception; 


rmi.RemoteEx 
ception; 


home component 


package \ > 
headfirst; 


package \ > 
headfirst; 

javax.ejb.*; 
intport java. 
rmi.RemoteEx 
ception; 


javax.ejb.*; 
in^ort java, 
rmi.RemoteEx 
ception; 


home component 


package \ > 
headfirst; 


package 

headfirst; 

iiq>ort 
javax.ejb.*; 
intport java. 
rmi.RemoteEx 
ception; 


inport 
javax.ejb.*; 
in^ort java, 
rmi.RemoteEx 
ception; 


home component 


package \ > 
headfirst; 


package 

headfirst; 

javax.ejb.*; 
intport java. 
rmi.RemoteEx 
ception; 


javax.ejb.*; 
inqport java, 
rmi.RemoteEx 
ception; 


home component 


Change an existing customer’s phone number 


Find all the customers in Pleasantville 


Delete all customers previously declared ‘inactive’ 


Delete a specific customer 


package \ > 


package \ > 

inport 

javax.ejb.*; 
intport java, 
rmi.RemoteEx 
ception; 


in^jort 
javax.ejb.*; 
inport java, 
rmi.RemoteEx 
ception ，- 


home component 


Get the street address of a specific customer 
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entity Remote component interface 


Ewtity bean Remote compowewt interface 

An entity bean’s component interface is just like a session bean’s — it has business 
methods, and it extends javax.ejb.EJBObject. That means a client can see the methods 
you’ve declared in your component interface, as well as the methods from EJBObject 
(getHandle(), remove(), etc.). 

But what kinds of business methods go in the component interface? 

The methods related to a single entity! 

When the client has a reference to an entity bean (which means a reference to the 
bean’s EJB object, of course), the client has a reference to a single, specific entity. 

Fred Flintstone, #999. Marge Simpson, #728. Roy Rodgers, #1957. 

So what might a client want to do with a reference to, say, Marge Simpson? Delete 
her, change her last name, get handle, or get her home so that the client can get 
references to other customers. Keep in mind that our simple Customer bean isn’t very 
useful yet, with methods to get or set only the Customer name. Later, we’ll build it out. 


What YOU write: 


What the CLIENT sees: 



*tV>c actual 
V\'icvavtV>Y ^ Remote 

c %Ws EJBObjcti aiad 


〈〈 interface 》 

_ Customer _ 

getLastName() 
setLastName(String s) 

getFirstName() 
setFirstName(String s) 



〈〈 interface 〉〉 

_ Customer _ 

getLastName() 
setLastName(String s) 



getFirstNamef) 
setFirstNamefString s) 



getPrimaryKey() 

getEJBHome() 

getHandlef) 

remove() 

isldentical() 


- ft 工工： 

t 乇 6a ” a66CSS 》 
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Ewtity bean Remote component interface 


entity bean intro 


package headfirst; 

import javax.ejb.*; 

import java.rmi.RemoteException; 

public interface Customer extends EJBObj ect { 

public String getLastName() throws RemoteException; 

public void setLastName(String lastName) throws RemoteException; 

public String getFirstName() throws RemoteException; 

public void setFirstName(String firstName) throws RemoteException; 
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Rules for the Remote component interface 

① Import javax.ejb.* and java.rmi.RemoteException 
(§) Extend javax.ejb.EJBObject 

③ Declare one or more business methods, that throw a RemoteException 

Arguments and return types must be RMI-IIOP compatible (Serializable, 
primitive, Remote, or arrays or collections of any of those) 

伞 You can have overloaded methods 

Each method must declare a RemoteException 

伞 You can declare your own application exceptions, but they must 
NOT be runtime exceptions (in other words, they must be compiler- 
checked exceptions — subclasses of Exception but not subclasses of 
RuntimeException) 

^ Methods can have arbitrary names, as long as they don’t begin with “ejb”. 
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entity bean intro 

Ewtity bean Remote home interface 

How ifs different from a session bean home interface: 

① You’re more likely to find an existing entity than create a new one 

As a client, you’ll probably spend a lot more time using references to existing 
customers, than you’ll spend creating new customers. Whether you’re updating 
a specific customer or doing a batch operation on many customers, you’ll need 
home interface code that lets you select customers, more than you’ll need creation 
methods. In fact, the create () method is optional for entity beans! (Because you 
might have a policy that says new entries in the database must be done directly 
through a database admin tool, for example.) But you’re required to put at least 
one finder m^Xhod for an entity bean home — you can have as many finders as you 
like, but you must have findByPrimaryKey (String primaryKey) in every entity home. 

(Which means it might be the only method declared in the home interface.) 

② You might want to do queries that involve more than one entity 

Since session beans represent process, it doesn’t make sense to, say, get multiple 
instances of the same process. But with entity beans, you might want to do the 
same things you’d do on a database table, like find all the customers who live in 
Helsinki and enjoy surfing. 


What YOU write: What the CLIENT sees: 




〈〈 interface 〉〉 

CustomerHome 

createfString last, String first) 
findByPrimaryKey(String key) 
findByCity(String city) 


〈〈 interface 〉〉 

CustomerHome 

createfString last, String first) 
findByPrimaryKey(String key) 
findByCity(String city) 




rtWs a 
.tctavASC botv> — 

vS ^ ^ 


getEJBMetaDataf) 
getHomeHandle() 
remove(Handle h) 
remove(Object key) 
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entity home interface 


What docs the client really wawt 
from aw cwtity bean home? 


以:㉟⑽一 


«interface» 

CustomerHome 

Customer create(String last, String first) 
Customer findByPrimaryKey(String key) 

((Collection findByCity(String city) 


With session beans, that was easy — a reference to the 
component interface. And that’s exactly what the create () 
methods have to give back. 

With entity beans, it’s the same for create () methods — they 
must give back a reference to the component interface, in this 
case the component interface for the entity just created. 

But what if you want to find an existing entity bean 
instead of making a new one? That’s what the mandatory 
findByPrimaryKey() method is for, and it, too, must give back 
a reference to the component interface for the bean matching 
that key. 

But what if there isn’t a matching entity? If there’s no entity 
with that key in the database, the client gets a javax.ejb.Object 
NotFoundException. So the return type of findByPrimaryKey () 
is always the same as it is for create(), the component interface 
for that bean type. (And of course, the rules for session bean 
client interfaces applies here as well — a Remote home interface 
must give back the Remote component interface, and the local 
home interface must give back the local component interface.) 

This still leaves us with a method that cannot return the 
component interface: a multiple-entity finder, like our 
findByCity() method. Well, the client’s goal doesn’t change 
with multiple-entity finders; the client still wants a reference 
to the component interface, only this time it might be a whole 
collection of them. One for every customer entity in the city 
named in the method’s argument. 

Note: a client will not get an exception if a multi-entity finder 
can’t find any matches! Instead, the client will still get a 
Collection, but it will simply be empty. A Collection with no 
elements. Only single-entity finders throw exceptions when 
nothing matches the find criteria. 


The create and finder 
methods in an entity bean 
hone always give bad 
ike bean’s component 
interface. 

For create() and 
findByPriinaryKey(), the 
client gets a reference to 
one EjB object. 

For multiple - entity 
fenders, the client mi^ht 
get a wiiole PILE of 
references to EjB objects- 
one for eacK bean that 
matelies the query. 


274 Chapter 5 








Ewtity bean Remote home iwtcrfacc 


entity bean intro 


package headfirst; 

import javax.ejb.*; 

import java.rmi.RemoteException; 

import j ava.util.Collection; 

public interface CustomerHome extends EJBHome { 

public Customer create(String last, String first) throws CreateException, RemoteException; 

public Customer findByPrimaryKey(String key) throws FinderException, RemoteException; 

public Collection findByCity(String city) throws FinderException, RemoteException; 
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Whew finders have a dark side. 


I just thought of a pretty scary 
scenario... if I want my client to display a 
list of all my customers, ifs just one call 
to findAllQ, but THEN what? Are you telling me 
I would get back a zillion remote stubs? And 
then I’d have to make remote method calls on 
each one? That would take FOREVER not to 
mention all the bandwidth. That doesn't 
sound good at all... 



AViflia Remote interface, 
finder and create mefliods 
give back Remote stubs. 



make remote metkod calls 
on eacK one to get the data 

you want. 
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/ Wouldn't it be dreamy if there ― 

一 were a way to have methods in the 、 

home that could give back something other 
than EJB object references? If all I want is 
the data about the customers, like just a bunch 
of Strings to display, wouldn't it be great if 
~"I I could have a method in the home that 
V could give back just the data? But ifs 

probably a fantasy... _ _ ’ 


^JiereiSireriP 

Dumb Questions 

Wait... I thought it was bad design 
to make all those method calls from 
the client ANYWAY. Wouldn’t the client 
usually go through a session bean? And 
the session bean would then talk to the 
entity bean? 


A- 

Jr \ m Kind of. You’re thinking of the Ses¬ 
sion Facade J2EE design pattern. But even 
if you do put a session bean in front of an 
entity bean, the session bean is still a client. 
It might be a lot more efficient, because 
the session bean might not have as far to 
go on the network (and might even be on 
the same server as the entity). But if you’re 
keeping location-independence, then 
your session bean is still using the entity 
bean’s Remote interfaces, so there’s still a 
lot of overhead. 


Couldn’t you just have a business 
method in the component interface that 


returns data? Like, return a collection of 


Strings? 


A ： 


You’re getting warmer. Yes, that’s 
the way you might have done it in EJB 1.1. 
But that’s kludgey, because you have to 
first get a reference to some customer, just 
so you can ask f/?af customer to give you 
back the data for all customers. 
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Home business methods to the rescue 

That’s right... business methods aren’t just for the 
component interface, when you’re talking about entity 
beans. As of EJB 2.0, an entity bean home can have 
methods that — drum roll — don’t have to return component 
interfaces! Home business methods can return anything 
(with the one restriction, of course, that Remote home 
methods return values that are RMI-IIOP compliant). 

Home business methods are great for batch operations, 
or for query methods where the client doesn’t need — or 
want — EJB object references, but simply wants the 
entity’s data (in other words, the data for one or more 
of the entity’s persistent fields). For example, we might 
put a home business method in the Customer bean 
like, getAllCustomerlnfo (), that returns a collection of 
Strings, with whatever pieces of data you’ve decided make 
up the customer’s info. Better yet, you can send back a 
collection of Customerlnfo objects, where Customerlnfo 
is a class that simply holds the data (and getters) for the 
Customer’s persistent state. That way, the client can make 
local calls to get the data it needs out of the Customerlnfo 
objects, without having those calls be remote calls on the 
component interface. 

A Customerlnfo class is an example of a Value Object class 
which is, in a nutshell, just a class with getters (and possibly 
setters, depending on the design) representing the entity’s 
persistent fields). And it, too, has a dark side — the data 
starts to become stale the moment after the Value Object is 
created. 

We could tell you now, but then we’d be robbing you of 
such a valuable opportunity to apply a little neural effort. 

So for now, why don’t you think of why sending back 
Customerlnfo objects, that the client could then interrogate 
(i.e. call methods on) at its leisure, could have a downside. 
We’ll use Value Objects a lot, but you have to be aware of 
the tradeoffs when choosing between using a home finder 
method that returns EJB object references (especially when 
the references are Remote) vs. a home business method that 
returns Value Objects. 


Home business methods 

can return somediing 
otker ilian EjB object 
references! TKe/re 
perfect for queries Wiere 
the client just wants the 
entity data, not references 
toilie entities themselves. 

They’re also great for 
batcK operations, or 
anything else you mi^rt 
want to do widi more 
than one specific entity, 
wiien you don’t want to 
return references to ike 
component interface. 
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Rules for the Remote home interface 


entity bean intro 


① Import javax.ejb.* and java. rmi. Remote Exception 

(2) Extend javax.ejb.EJBHome 

( 3 ) Declare (optionally) one or more create() methods, which MUST 
return the Remote component interface, and declare both a 
RemoteException and a CreateException. Each create() method must 
begin with the prefix “create”. 

④ Declare the findByPrimaryKey() method, which MUST 
return the Remote component interface, and declare both a 
RemoteException and a FinderException 

⑤ Declare (optionally) one or more other finder methods, which 
MUST return either the Remote component interface (for 
single-entity finders), or java.util.Collection (for multiple-entity 
finders). All finders must declare both a RemoteException and a 
FinderException 

⑥ Declare one or more home business methods 

Arguments and return types must be RMI-IIOP compatible (Serializable, 
primitive, Remote, or arrays or collections of any of those) 

You can have overloaded methods 

Each method must declare a RemoteException 

伞 You can declare your own application exceptions, but they must 
NOT be runtime exceptions (in other words, they must be compiler- 
checked exceptions — subclasses of Exception but not subclasses of 
RuntimeException) 

I Methods can have arbitrary names, as long as they don’t begin with 
“create” ， "find", or “remove”. 
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For the four database operations (SQL commands) a client might 
want to do with an entity bean, list the methods in the bean’s 
interface(s) that are related to those database operations. No, you 
don’t have to know SQL, but you definitely have to understand the 
implications of the four database operations, and you must know 
how they correspond to methods in the bean class. 

From the list of the methods in the interfaces, fill in the method or 
methods that correspond with the database operation. 


INSERT : 


DELETE : 


UPDATE : 


SELECT : 


《 interface 》 

CustomerHome 


〈〈 interface 》 

Customer 


create(String last, String first) 
findByPrimaryKey(String key) 
findByCity(String city) 


getLastNamef) 
setLastName(String s) 


getEJBMetaDataf) 
getHomeHandlef) 
remove(Handle h) 
remove(Object key) 


getFirstNamef) 
setFirstName(String s) 


getPrimaryKey() 
getEJBHome() 
getHandlef) 
remove () 
isldentical() 
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Session bean crcatcO vs. entity bean crcatcO 


entity bean intro 


① Stateful session bean create() 

■ Client calls it to get an EJB object reference to a new just-for-me 
stateful session bean. 

■ It can (and frequently does) have arguments, that the bean uses to do 
client-specific initialization (before running any business methods). 

■ The Container makes a new session bean when the client calls create() 


② Stateless session bean create() 

■ Client calls it to get an EJB object reference to a bean 

■ It has no arguments, and the bean does not do any client-specific 
initialization (since at the time the bean’s ejbCreate() is 
called, the bean has no association with a client!) 

■ The Container does not make a new session bean when 
the client calls create(), and does not pull one out of the 
pool until the client invokes a business method. 


③ Entity bean create() 

■ Client calls it to insert a new row in the database!* 

Although the end result for the client is still an EJB object 
reference (in this case, to the newly-created entity). 

■ It will virtually always have arguments (although they 
aren’t mandatory, but it’s kinda hard to imagine a cre- 
ate() without them... like, “Hey database, create a new 
customer... no, I don’t have any name or ID or anything... 
just make some stuff up”). 

■ The Container does not make a new entity bean, but it does pull one 
out of the pool to run the ejbCreate() method. Remember, the ejbCre- 
ate() method has to take the create() arguments and somehow create 
a new entity in the underlying persistent store (or at least support the 
Container in creating a new entity). 


Ma^ c 



id, 


date, 
mode, 
ew create 

... 
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Session bean removcO vs. cwtity bean rcmovcO 


① Stateful session bean remove() 

■ Client calls it to tell the Container that he’s done with the bean 

■ Container calls the bean’s ejbRemove() (unless the bean is already passivated) and 
kills the bean (think: food for the garbage collector) 

■ Client will get an exception if he tries to use the EJB object reference after removing 
the bean. 


② Stateless session bean remove() 

■ Client calls it to tell the Container that he’s done with the bean 

■ Container gets the call and says, “Like I care? Do you honestly think you’re that 
important? This bean is already back in the pool baby.” The Container does not call 
a bean’s ejbRemove(). Think about \{—which bean’s ejbRemove() would it call? 

■ Client will get an exception if he tries to use the EJB object reference after removing 
the bean. 


③ Entity bean remove() 

■ Client calls it to tell the Container to delete the entity with this primary key. 

■ Container calls the bean’s ejbRemove() method and—if the bean supports client- 
triggered removal—the entity is deleted from the underlying persistent store. In other 
words, the row in the database is history. Gone. Poof. 

■ Client will get an exception if he tries to use the EJB object reference after removing 
the bean. 

■ In fact, NO client will be able to use an EJB object reference to that entity! 
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entity bean intro 


I hate to do this, really, but I 
have no choice. #86 MUST be 
removed from the database. 

So if you've got any last words, you 
better do it in your ejbRemove()... 



remove() on a session bean 
means the client is done with 
the bean. 

remove() on an entity bean 
means EVERYONE is done with 
the bean! 
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entity removal 





Looks like somebody 
didn’t read the script... You 
know that's not how it works... it’s 
not the bean instance that's killed, 
but the entity in database. You 
just go back to the bean pool 
when the client calls 
remove() 


But I never get to do a death 
scene. I know ifs only the database 
entity that gets deleted, but I just 
wanted something a bit more dramatic 
for a change. I know I'll die if I throw an 
unchecked exception, but that could take 
forever... and I was hoping to get a 
part in ’、 Lord of the Beans" and... 



284 Chapter 5 





entity bean intro 


Ewtity/beaw/mstawce death 


So we all know that an entity bean is a representation of 
some real entity in an underlying persistent store (usually as 
a row in a database, blah, blah, blah). But there’s still some 
confusion about what distinguishes an entity from an entity 
bean from an entity bean instance. 

Entity 

The real thing in the underlying persistent store. The row in 

the database (although it can be more complex). An entity 
dies when its row is deleted from the underlying store, either 
through a direct database delete (like, someone using a 
database admin tool), or because someone calls remove () on 
the bean’s home or component interface. 


A client can till an entity, 
by calling remove。on a 
bean, op deleting the data 
from the database directly. 

But only the Container op a 
server crasK can till a bean 


Entity bean 

The component that represents the underlying real entity. 

But this one’s tricky... is it the class? Is it the interface} Is it 
the instance of the bean class? During development and 
deployment, the entity bean is the whole component (the 
two interfaces, DD, and bean class). But at runtime, it can 
get a little fuzzy. S ometimes we use “entity bean” to describe 
the possibility of representing a particular entity as a bean. 

In other words, if there’s an entity for Bo Rodgers in the 
database, then we can say that there is a Bo Rodgers entity 
bean, even if there’s no bean instance currently representing 
that entity! If an entity exists for a particular bean type (like 
Customer Fred Foo), the entity bean for that entity is said to 
exist. An entity bean is said to die when its underlying entity 
is deleted, as in, “There’s no Fred Foo entity bean.” But... that 
doesn’t mean the instance on the heap dies. 

Entity bean instance 

The instance of the bean class on the heap. Bean death is 
intimately tied to the database, but bean instance death (as 
in, “you’re headin’ for garbage collection, pal”）is tied to the 
whims of the Container, or a server crash. 


Yes, it really is that confusing. You have to know the context to 
know how the word ‘bean’ is being used. If it means the bean- 
representing-the-entity, then that bean will die when the entity 
dies, and the EJB object for that entity goes away. But — and 
here’s where it gets weird — the entity bean instance doesn’t 
die; it just goes back to the pool. Think of the phrase “entity 
bean” as more conceptual than physical. In most cases, we 
won’t have to distinguish between the bean and its instance, 
or the distinction will be so obvious that its not an issue. 


instance. 


If we say “entity bean #42 
was tilled”, iiie underlying 
entity is gone, and the EjB 
object for #42 is gone, but 
ilie bean instance iiiat Kad 


been playing #42 survives. 


Well, ifs been great 
playing you, really, but now 
ifs time for you to go to a better 
place, ril think about you while I*m 
floating on one of those little 
inflatable mattress 
things. 


o 



Darko Donny 42 

t 

wt’rty P|K v/iiCh a 
d ietrrt dal Is vemovcO 
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entity removal 


Client calls remove() 



1 Client calls remove() on the EJB object stub for entity #86 

2 The remove() method invocation is passed to the EJB object. 

3 The Container calls ejbRemove() on the bean. 




1 The Container or bean deletes the entity in the database. 

2 The bean loses its identity (in other words, it is no longer representing entity #86) and moves 
back to the pool. Meanwhile, the EJB object for #86 is deleted, so the client’s stub will throw an 
exception if the client uses it to invoke a method. 
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BULLET POINT 


Entity bean client view 


entity bean intro 


■ An entity is a real thing that exists outside of EJB, in a 
persistent store, and an entity bean is an 00 repre¬ 
sentation or realization of an entity. 

■ Clients use entity beans to do database operations, in 
an 00 way. Operations include creating new enti¬ 
ties (database inserts), deleting entities (database 
deletes), updating entity state (database updates), and 
searching for/on entities (database selects). 

■ An entity bean Remote component interface extends 
EJBObject. There’s not a separate interface for ses¬ 
sion beans and entity beans. That means that the 
client will see all of the methods in your component 
interface, plus the five additional methods from EJ¬ 
BObject. 

■ Entity bean component interfaces usually contain 
getters and setters for field values that correspond to 
columns in a database table, such as getLastName(), 
getHomePhone(), setFirstName(), etc.) 

■ Entity bean component interface methods are usually 
meant to be run by a specific, uniquely-identifiable 
entity. For example, calling getLastName() on the 
entity with primary key #420, returns the last name of 
the entity in the database with the primary key #420, 
Dan Doof. 

■ The rules for how you write an entity bean Remote 
component interface are the same as the rules for 
session beans, including: extend EJBObject, declare 
RemoteExceptions on all methods, use only RMI-IIOP 
types for arguments and return values, don’t begin 
method names with the prefix “ejb”, etc. 

■ An entity bean home interface is substantially different 
from that of a session bean, because entity beans are 
typically found rather than created. In other words, the 
client is more likely to try to access an existing entity 
as opposed to making a new entity (which means a 
new row in the database.) 


■ In an entity home, a create() method is not required 
(since create() method in entity beans are for inserting 
new entities into the database, and you’re not required 
to allow your clients to do that.) 

■ Entity bean home interfaces can have single-row or 
multi-row finder methods. Both create and finder meth¬ 
ods return the component interface of a bean, although 
multi-entity finders return a Collection of component 
interface references. 

■ Every entity bean home is required to have at least 
one method—the findByPrimaryKey() method that 
searches for a particular entity and returns its com¬ 
ponent interface (i.e. a reference to that entity’s EJB 
object), or throws an exception. 

■ Multiple-entity finders do not throw an exception if no 
matching entities are found. They simply return an 
empty collection. 

■ Entity home interface can also have home business 
methods, for operations that apply to more than one 
entity, as opposed to one specific entity. Batch updates 
would be a good use for a home business method. 

■ The real benefit of home business methods is 
that—unlike create and finder methods—home busi¬ 
ness methods can return something other than an EJB 
object reference. If the client wants only data, say, a 
Collection of Strings representing the name and phone 
number of each customer, a home business method 
can do that while a finder can not. 

■ An entity bean create() is very different from a session 
bean create。, because an entity bean create() inserts 
a new entity into the underlying persistent store (i.e. 
new row in the database). 

■ An entity bean remove() is dramatically different from a 
session bean remove()! When a client calls remove() 
on an entity bean, it’s to delete the entity from the data¬ 
base! That means everybody is done with the bean. 
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coffee cram mock exam 


c 办尹腎它它 

"TKcck Sxom 



What is true concerning locating an entity bean’s home interface? 

Q A. The narrow () method should be used for a local home interface. 

口 B. The narrow () method should be used for a remote home interface. 

口 C. The narrow () method should be used for both local and remote 
home interfaces. 

口 D. The narrow () method should be used for neither local nor remote 
home interfaces. 


Which capabilities are found in an entity bean’s remote component interface? 
(Choose all that apply.) 

[I A. creating new entity objects 
口 B. finding existing entity objects 
Q C. removing existing entity objects 
口 D. executing a home business method 
Q E. retrieving the EJBMetaData interface 


Which are ways in which a client can get a reference to an existing entity 
object’s local component interface? (Choose all that apply.) 

□ A. Call ejbCreate () 

□ B. Call getSessionContext () 

Q C. Obtain the reference from the handle. 

口 D. Receive the reference as a parameter in a method call. 

Q E. Use a finder method defined in the local home interface. 
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How many create methods can be defined in an entity bean’s local home 
interface? 

□ A. 0 

Q B. Only 1 

□ C. 0 to 1 

口 D. 0 to many 
口 E. 1 to many 


Which are ways in which a client can get a reference to an existing entity 
object’s remote component interface? (Choose all that apply.) 

□ A. Call ejbCreate (). 

口 B. Obtain the reference from the handle. 

口 C. Call a method on the entity object’s primary key. 

口 D. Receive the reference as a parameter in a method call. 

口 E. Use a finder method defined in the remote home interface. 


Which approach (es) can be used on a primary key class to determine if two 
keys refer to the same entity? (Choose all that apply.) 

口 A. Using the == operator. 

Q B. Using the equals () method. 

□ C. Using the isldentical () method. 

Q D. none of the above. 


Which approach (es) can determine whether two entity EJB object references 
refer to the same entity object? (Choose all that apply.) 

Q A. Using the == operator. 

Q B. Using the equals () method. 

□ C. Using the isldentical () method. 

口 D. none of the above. 
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What’s true about the client’s view of an entity bean’s remote component 
interface? (Choose all that apply.) 

口 A. Multiple clients can access the same entity object concurrently. 

Q B. New entity beans can be created using a method in this interface. 
Q C. Entity beans may not survive a crash of the container. 

Q D. Business methods cannot return a reference to the entity object. 


How many finder methods can be declared within an entity bean’s local home 
interface? 

□ A. 0 

Q B. Only 1 

□ C. 0 to 1 

口 D. 0 to many 
口 E. 1 to many 


10 Which is a legal declaration for a local home interface’s create () method? 
(Choose all that apply.) 

□ A. public Cust create(int x); 

Q B. public void create(int x) throws CreateException; 

□ C. public Cust create(int x) throws CreateException; 

□ D. public Cust create(int x) throws CreateException , 

RemoteException; 


ir 


Which is a legal name for an entity bean home business method? (Choose all 
that apply.) 

口 A. create 
Q B. createCust 
口 C. remove All 
Q D. findCust 
Q E. selectCust 
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"TKoc^ Sxom /ia^en^ 


What is true concerning locating an entity bean’s home interface? 

Q A. The narrow () method should be used for a local home interface. 

OT B. The narrow () method should be used for a remote home interface. 

Q C. The narrow () method should be used for both local and remote 
home interfaces. 

口 D. The narrow () method should be used for neither local nor remote 
home interfaces. 


( 和 :iio) 


Which capabilities are found in an entity bean’s remote component interface? 
(Choose all that apply.) 




& ' 一 howc - 

Q B. finding existing entity objects 

^ C. removing existing entity objects 

Q D. executing a home business method . , 4 

一 home methods 

口 E. retrieving the EJBMetaData interface 


: e 


Which are ways in which a client can get a reference to an existing entity 
object’s local component interface? (Choose all that apply.) 


(s? 仏 : "1) 


□ 

□ 

□ 


A. Call ejbCreate () - wc said : ) 


B. Call getSessionContext () 

C. Obtain the reference from the handle. 






D. Receive the reference as a parameter in a method call. 

[Q E. Use a finder method defined in the local home interface. 
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^1 How many create methods can be defined in an entity bean’s local home 
interface? 


(s 〜 


11 * 5 ) 


5 


6 


1 


□ A. 0 

Q B. Only 1 

□ C. 0 to 1 
5^ D. 0 to many 
口 E. 1 to many 




.Vova Aoy\ t nave 

*to t 


r\V*i 




(s?e6: "1) 


Which are ways in which a client can get a reference to an existing entity 
object’s remote component interface? (Choose all that apply.) 

□ A. Call ejbCreate (). - y/e sd'id £)<|ST|K^ 

^ B. Obtain the reference from the handle. 

Q C. Call a method on the entity object’s primary key. 

^ D. Receive the reference as a parameter in a method call. 

^ E. Use a finder method defined in the remote home interface. 

Which approach (es) can be used on a primary key class to determine if two (s^c^ : 12*0 -⑴) 
keys refer to the same entity? (Choose all that apply.) 

□ A. Using the ^ operator. 一 、 . 

OB. Using the equals () method, sd^e kc'/! W hicn 

□ C. Using the isldentical() method. — is/d C ^i^|0 is U 

[ID. none of the above. 


Which approach (es) can determine whether two entity EJB object references 
refer to the same entity object? (Choose all that apply.) 

口 A. Using the == operator. 一⑽ aW() k 巧 —M 

Q B. Using the equals () method. 一二 \ 、切、 ? 一 a ” 岭 
^ C. Using the isldentical () method. 

Q D. none of the above. 


(s ? e6： ⑽-仙 
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What’s true about the client’s view of an entity bean’s remote component 
interface? (Choose all that apply.) 

A. Multiple clients can access the same entity object concurrently. 

Q B. New entity beans can be created using a method in this interface. 

口 C. Entity beans may not survive a crash of the container. 

口 D. Business methods cannot return a reference to the entity object. 

How many finder methods can be declared within an entity bean’s local home 
interface? 

□ A. 0 

Q B. Only 1 

□ C. 0 to 1 

□ D. 0 to many ^ 

Cf E. 1 to many - “聲一砍和 


(s?e6: I ⑽ 




IIW 




11 * 5 ) 


□A. public Cust create(int x); 


Which is a legal declaration for a local home interface’s create () method? 

(Choose all that apply.) 

^ 乂七 void, 

Q B. public void create (int x) throws CreateException ; - mus*t \rctu\nr> 

*m*tcv--Padc 

C. public Cust create(int x) throws CreateException; 

□ D. public Cust create(int x) throws CreateException , 
RemoteException; ^ | oda | 七 Wov/ 


Which is a legal name for an entity bean 
that apply.) 


home business method? (Choose all 硬 ^ 


[I A. create 
Q B. createCust 
口 C. remove All 
Q D. findCust 
ar E. selectCust 




'Create 
avc 


a 


OVC p. 

reserved ? 代七， 
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6 bean/entit/ syncjirpn 

+ Being an Entity Bean 





As an entity bean, I lead the 
glamorous life of an actress. I spend most 
of my time in the pool, but even when I do 
work, rm never bored. I always get to play 
different roles... yesterday I was Jeanne 
Rose, today I’m Marilyn Malone, and 
^ tonight I’ll be playing the part of ^ 
I Doug Adams... J 




Entity beans are actors. As long as they’re alive, they’re either in the pool or 


they’re being somebody. Somebody from the underlying persistent store. In other words, 
an entity from the database. When a bean is playing a part, the bean and the underlying 
entity have to stay in sync. Imagine the horror if the bean is pretending to be, say, Audrey 
Leone, and someone lowers Audrey’s credit limit in the database... but forgets to tell 
the bean. The bean, acting as Audrey, is happily authorizing purchases for more than 
Audrey’s current limit. Or what if a client uses the bean to modify Audrey’s address, but 
the bean hangs on to the new info without telling the database... yikes! 


this is a new chapter 
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exam objectives 




6.1 Identify correct and incorrect statements 
or examples about the Bean Provider’s 
view and programming contract for CMP, 
including the requirements for a CMP 
entity bean. 

6.6 Identify the interface(s) and methods 
a CMP entity bean must and must not 
implement. 

7-1 Identify correct and incorrect statements 
or examples about the lifecycle of a CMP 
entity bean. 


7.2 From a list, identify the purpose, behavior, 
and responsibilities of the Bean Provider 
for a CMP entity bean, including but not 
limited to: setEntityContext(), 
unsetEntityContext(), ejbCreate(), ejb- 
PostCreate(), ejbActivate(), ejbPassivate(), 
ejbRemove(), ejbLoad(), ejbStore(), ejb- 
Find(), ejbHome(), and ejbSelect()_ 

7-3 From a list, identify the purpose, behavior, 
and responsibilities of the Container for a 
CMP entity bean, including but not limited 
to: setEntityContext(), unsetEntityContext(), 
ejbCreate(), ejbPostCreate(), ejbActivate(), 
ejbPassivate(), ejbRemove(), ejbLoad(), 
ejbStore(), ejbFind(), ejbHome(), and ejb- 
Select(). 


Ct mecuuL. 

This objective can hit you on almost anything related 
to entity beans, so you pretty much have to know it 
all, including the details of a CMP entity bean lifecycle, 
the container callback methods of javax.ejbEntityBean, 
what you must write in a bean class, and what a bean 
can get from its EJBContext. 

You have to know that passivation in entity beans 
is different from session bean passivation, because 
entity beans go back to a pool after ejbPassivate(), 
but stay as heal-living objects. You must know that 
entity bean creation is also completely different for 
entity beans, and that a create() call on an entity 
bean means “insert a new entity into the underlying 
persistent store.” You have to know that remove() on 
an entity bean is more drastic for entity beans than 
session beans — an entity bean remove deletes the 
entity from the database! 

You must be able to look at an entity bean method and 
know the circumstances under which that method is 
called, and what you should do in that method. For ex¬ 
ample, you need to know that in a bean’s ejbCreate() 
method, the bean cannot get a reference to its EJB 
object, but that it can get that reference in ejbPostCre- 
ate(). 

You need to know which methods you’re required to 
write into your bean, and which are left to the Con¬ 
tainer. For example, you need to know that the Bean 
Provider must write abstract getters and setters for 
persistent fields, but must define finder methods only 
in the home interface, not the bean class. 
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From a list of behaviors, match them with 
the appropriate EntityContext method 
responsible for that behavior 


Identify correct and incorrect statements 
about an entity bean’s primary key and 
object identity. 


You have to know the methods of EntityContext, as well 
as the circumstances under which you can call those 
methods. For example, you should know that if you’re 
running in the setEntityContext() method, you can use 
your special JNDI namespace to look up a reference to 
a DataSource, but that you’re not allowed to access the 
underlying database from that method (there’s no mean¬ 
ingful transaction, so the Container won’t let you do it.) 


You should know that you can’t call getUserTransaction() 
on your context, because entity beans must use con¬ 
tainer-managed transactions, and getUserTransaction is 
for bean-managed transactions only. 


You have to know that an entity bean must have a 
unique identity (no two beans can have the same 
primary key), and that a CMP bean’s primary key must 
be either one of the bean’s persistent fields, or a custom 
primary key class, whose fields are all from container- 
managed fields defined in the bean. You must know that 
the primary key class type must be Serializable, and that 
it must have a valid override of equals() and hashcode(). 
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The real power of cwtity beans is 
synchronization 


The bean and the underlying row in the database must 
stay in sync! Remember, the bean is not the entity — the 
bean is a representation of the real entity. The bean is 
an OO way of working with the data, but the entity in 
the database is the only true entity. If the entity in the 
database dies (i.e. is deleted), the bean for that specific 
entity dies too (although the bean instance still lives, as 
you saw in the last chapter). 

The Container’s job is make sure that the entity and the bean 
stay in sync, so that nobody’s looking at a stale bean or a 
stale row in the database. Keep in mind that the entity 
bean may not be the only way to get into the database! 

In fact, in most cases the Bean Provider (you) will have 
no way to know for certain, during development, if your 
bean is the only way anyone will ever be able to get to the 
entity data. 

For example, your Customer database might be used 
by a bunch of apps in your company, including some 
that work directly with the database and some that go 
through the Customer bean in an EJB application. 

If a client has a reference to a bean, the client might 
change the bean’s state by, say, calling a setter method. 

If that setter method corresponds to one of the bean’s 
persistent fields (in other words, a column in the 
table like address), the bean and the database will be 
temporarily out of sync. The database won’t have the 
current address until the bean updates the database! 

Now think what a disaster it would be if the bean caches 
the new data for the entity, without telling the database. 

If someone comes along with another application and 
asks for that Customer’s address from the database, That 
Would Be Bad. 

And the opposite scenario is bad as well: if someone 
updates the database, the bean needs to know! Otherwise, 
the bean is out there in the EJB app, representing the 
entity in the database, but the bean isn’t a true reflection 
of the entity’s state. In other words, the bean is stale. 
Which means, perhaps, useless. 


The Container always knows when the 
bean and the database (the underlying 
entity) must be synchronized, so that 
neither one has ‘stale’ data. 



OK, I have 
the bean for Chris 
Martin, and now I want to 
change his address to 72 
Clock Street. 5o, I’ll 
call setAddress() on 
the bean., 
o' 


Cool. I’ve 
updated my bean 
state with the new 


address. 


(bean currently 
playing #72) 


HELLO! Excuse me... 

I’m glad you're all having a 
nice chat about it, but don't you 
think the database might like 
to know about that address 
change??!! 
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Oh no! 


The entity bean and the entity it 
represents have different data! 


First: Chris 
Last: Martin 
Key: 100 
Address: 

Phone: 555-1212 


78 Clock st 




First 

Last 

Key 

Address ) 

Phone 

Chris 

Martin 

100 

42 Foo st.^ 

555-1212 

Fran 

Healy 

16 

200 Bar rd. 

555-3434 

Bela 

Fleck 

5 

25 Pick lane 

555-5656 


The Container’s most important entity bean job is to make 
sure that this scenario — where the bean and the database 
are out of sync — doesn’t cause any damage. 


The Container has to make sure that: 


■ While somebody is working with the bean (and potentially changing 
its state), nobody can work with the real entity in the database. 

■ Once an entity bean’s state has been updated, the database has to 
be updated, before anyone else can access that record in the data¬ 
base. 

■ Before the bean can run any business methods on a particular entity’s 
behalf, the bean has to be refreshed with the entity’s state. In other 
words, before the entity bean for Joe Bloggs #88 can run a getCred- 
itLimit() method, the Container has to load the entity bean up with the 
most current data for Joe Bloggs. Otherwise, the bean might return 
the wrong credit limit—the limit that was in place the last time the 
bean was loaded up with Joe's data from the database. 
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Uh-oh. Now you've got me even MORE 
worried. Doesn't this mean, then, that the 
bean can get stale in between EVERY business 
method call? Are you telling me you have to make a 
trip to the database to refresh the bean's data with 
the actual database data, just in case it changed, 
every time the client calls a method on the bean? 

If THATs true, you might as well just go 
straight to the database! 



No! That’s not what I'm 
saying, but I can see how it might 
look like that. The missing piece here 
is the transaction! As long as the bean’s 
methods are being called as part of a 
single transaction, the bean doesn’t 
have to synchronize its state with 
data in the database. 



See, when the client calls a business 
method, and that method starts a 
transaction, I tell the database to lock the 
entity! (For now, you can think of it as locking 
the row, although it might actually be something a 
little different). With the real entity locked, the 
bean can’t become stale, because nobody can get 
into the entity through the database. I won't tell 
the database to release the lock until the 
transaction is over, so the bean is safe. 


O 




J1 
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① r 


How the entity bean and the underlying 
entity stay synchronized 



Client calls a 
business method. 


② 


J 


Container intercepts the 
call and starts a transaction ， 
BEFORE getting the bean. 


Container tells the database to lock the 
row (to anyone else but the Container). 



Last 

First 

PKey 

j Poly 

Morphism 

72 

Dewey 

Cheatem 

900 


⑤ 

C3 



Bean runs multiple business 
methods in the same transaction ， 
knowing that the underlying 
entity data in the database can’t 
be changed (because the row for 
this entity is locked). 



Container tells the database to release 
the lock on the entity row. 




Container loads the bean 
with the entity state from the 
database. Now nobody can 
except the bean can change 
the entity data. 




Container ends the transaction, 
but first it updates the 
database with whatever new 
state the bean might have 
been caching on behalf of that 
entity (like, if someone called 
setAddress() on the bean). 




Last 

First 

PKey 

! Poly 

Morphism 

72 

Dewey 

Cheatem 

900 
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The owly question is WHO does the work 
whew ifs time to sywchrowizc 


The Container always knows when the bean and the database 
entity must be synchronized. It knows based on transactions. 

If a client calls a method on a bean, and that method starts a 
new transaction for the bean, the Container knows that the 
underlying entity in the database may have changed since the 
last time this bean was loaded up with this entity’s data. So the 
Container forces the bean to refresh its state by loading in the 
entity’s data. 

And of course the reverse is true. If the bean completes a 
method, and this method was the end of the transaction, the 
Container will tell the database to release the lock on this 
entity in the database. But... during the time when the row 
was locked, the bean might have been happily caching data 
that represents the newly-changed state of the entity (like a 
new address or phone number). In other words, the client 
might have been calling setter methods on the bean, with the 
intention of causing an update in the real database. The client 
wants to update a record. So, the Container knows it must 
force the bean to update the data in the database with the 
bean’s state, before the Container tells the database to release 
the lock on that entity. 

OK, so the when is not the issue. And that’s important, because 
otherwise you, the Bean Provider, would have to work out the 
business logic to know exactly when there was a danger that 
the bean and entity are out of sync. And you can just imagine 
how quickly you could corrupt the state of your database... 

The real issue is who does the database access? And there are 
only two choices: it's either you or the Container. 

If you write the database access code, you write JDBC 
statements in the callback methods the Container calls when 
its time to kick you and say, “Hey - time to go to the database!” 
On the other hand, if the Container writes the database code, 
you save yourself a lot of coding time and effort, and you’ll 
almost always get better performance. 


Container-Managed 
Persistence (CMP) means ^ie 
Container takes care of all 
iiie database access code for 
syncltfonization, including 
adding and deleting entities 
(records / rows in ^ie 
database). 

Bean-Managed Persistence 
(BMP) means YOU write the 
database access code (die 
JDBC statements), for \^ien 
the Container tells you its 
time to go to ^ie database. 

In EjB 2.0, you should 
use CMP . It saves you a 
lot of wort, and virtually 
always gives you better 
pepfomance. 
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Container - managed vs. beaM - managed persistence 


Container-managed persistence (CMP) 

■ Wimpy in EJB 1.1; greatly enhanced in EJB 2.0. 

■ The Bean Provider designs the entity bean class, choosing which of 
the bean’s fields are part of the bean’s persistent state. Persistent 
fields map to columns in one or more database tables. 

■ The Container keeps track of changes to the bean’s state and 
updates the real entity as needed. For example, if a client calls 
setLastName() on the bean, the Container knows that the real entity 
in the database has to be updated, so that if anyone else accesses 
the database for that entity (including non-EJB clients using some 
other means to get to the database), they'll see the current state 

of the entity. The Container makes the decisions on how to keep 
the bean and the real entity synchronized based on the state of 
transactions. (More on that later). 

■ The Bean Provider writes EJB-QL to tell the Container how to do 
selects. EJB-QL is like a subset of SQL, but with some 00 features. 
EJB-QL helps bridge the 00 world of your bean to the relational world 
of your real entity. 

■ Using information in the deployment descriptor, the Container writes 
the actual implementation of the CMP bean, including implementing 
the finder and select methods, and all of the database access code. 

In other words, if you’re a Bean Provider writing a CMP bean, you do 
not look up a resource connection factory for the DataSource, get 
an SQL Connection, or write any JDBC code. Not only is the data 
access code taken care of by the Container, but you can trust that the 
Container knows exactly when to go to the database. 


Bean-managed persistence (BMP) 

■ Bean Provider writes the database access code, including looking up 
a DataSource, getting a Connection, and sending JDBC statements 
to the database. It’s still better than if you didn’t use entity beans at 
all, because the Container will at least tell a BMP bean when to go 
to the database, so with BMP, you don’t have to put in logic to keep 
the bean and the database in sync. When the Container tells you to 
update the database, you just do it. 



The Container goes to the database 
when it needs to insert a new entity, 
delete and entity, update the database 
with new entity state (i.e. one or more 
columns in the entity row have changed, 
through the bean). 



The Container invokes a container call¬ 
back on the bean when the bean needs 
to do something with the database, and 
the bean code does the actual JDBC 
work. 
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Dumb Questions 


Doesn't the Container still have 
to give you the database Connection? 
Isn’t that the whole point of looking up 
a DataSource using resource factory 
references? If that’s true, then how can 
you do bean-managed persistence? 

Or is BMP a way to bypass all that, in 
which case you’d be bypassing the 
Container services for connection pool¬ 
ing and... 

Relax. Really. With BMP you 
still get your database connection 
from the Container, by looking up, as 
you said, a resource factory reference, 
javax.sql.DataSource. (Gee,you must 
have been reading ahead to the chapter 
on the EJB environment). Because you’re 
right,you need to get a connection 
from a connection pool managed by the 
Container. But once you get the connec¬ 
tion, for a BMP bean, you’re on your own 
for sending it statements to do INSERT, 
DELETE, UPDATE, SELECT operations. 

And while we’re here, remember that da¬ 
tabase access is not just for entity beans. 
ANY bean can go to the database as part 
of its business logic. Session beans and 
message-driven beans might find plenty 
of reasons to look something up or store 
something in a database.The difference 
between entity beans and the other two 
bean types is that entity beans exist only 
because there’s something in a data¬ 
base. Something the bean represents. 

So entity beans are, by definition, tied to 
something in a persistent store. 

Message-driven and session beans do 
not represent something in a database, 
although they may need to use some¬ 
thing in a database as part of their busi¬ 
ness logic. 


It seems like performance would 
be better — not worse — with BMP. 
Doesn’t BMP give you more control? 

• You have more flexibility with 
BMP, but not necessarily more control. 
And according to nearly all benchmarks 
against the major J2EE servers, not 
better performance.That might sound 
counterintuitive, but remember that the 
Container can do things that you can’t 
do from within bean code.Things like 
ganging multiple calls to the database, 
using native code to get in an out of 
the database faster than you could, lazy 
loading, dirty detection (neither of which 
are guaranteed by the spec, of course), 
and dozens of other tricks. 

We know it goes against the 
conventional wisdom that says if you 
want it done right, do it yourself, but 
keep in mind that the server vendors are 
competing for your business.They know 
performance matters to you.The 2.0 
spec added — and changed — a lot of the 
CMP specification for the sole purpose 
of giving the vendors more room for 
optimizing CMP. 
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A brief history ow the 
evolution of CMP 2.0 


Beginning with version 1.1 of the EJB spec, you could use both container- 
managed persistence (CMP) and bean-managed persistence (BMP). At 
the highest level, the difference between CMP and BMP is about who 
writes the database access code. 

With EJB 2.0, you can still use both, but there’s now very little reason 
to ever use BMP. The original EJB 1.1 specification for CMP entity 
beans was, um, weak. Clunky. Inefficient. Limited. Not That Good. And 
although many vendors were able to overcome many of the problems 
with CMP 1.1，the solutions were outside the specification, so your choice 
as bean developer was to use standard CMP but keep your portability, 
or step outside the spec (reducing your portability), but get better 
performance and features. 

When the EJB 2.0 spec was created, the team spent a great deal of time 
and effort talking to both end-user customers (bean developers) and 
container vendors, all of whom were very happy to describe the problems 
with CMP. In graphic detail, complete with suggestions for Sun on, “I’ll 
tell you what you can DO with your CMP bean spec...” 

The EJB spec team listened. And designed. And listened. And designed. 
And in the end, they came up with something awful. A solution that was 
an equal-opportunity pisser-offer. Vendors hated it. Developers hated it. 
People like us who had to explain the new technology to customers really 
hated it. So with the deadline upon them, the team scrapped much of 
what they’d done with CMP and came up with a much cleaner solution. 

With the new EJB 2.0 spec, CMP is lightyears ahead of where it was in EJB 
1.1 (or in the first, terrible version of the pre-release EJB 2.0 spec). And 
now, most developers using entity beans will use CMP. In fact, the exam 
doesn’t cover BMP at all, since it’s there more for legacy support or very 
special cases more than anything else. 

Because of the heavy shift to CMP (for reasons we’ll explore), we 
won’t cover BMP in this book. So from this point forward, we’re going 
to assume that we’re talking about CMP. The differences between 
the lifecycle, and the developer’s responsibility, for CMP vs. BMP are 
dramatic, so don’t forget that everything we talk about now will be from 
the perspective of a CMP bean, even if we don’t explicitly say that we’re 
referring to CMP. 


o 


-/Relax 

The exam 

doesn’t cover 
the history, gossip, or scandals 
of the EJB specification. 

Although it would have made 
the book much spicier if it did. 
Ah well... well just have to make 
do with the technical content. 

Still, we think the way a 
spec (any spec), evolves is 
interesting. Sun works hard 
to walk the fine line between 
having a meaningful spec 
with strong guarantees for 
the programmer, and one 
that’s vague enough on 
implementation details to 
let the vendors compete 
on the performance of their 
implementations. 

Regardless, there’s nothing on 
the exam about the different 
versions of the spec. As long as 
you know what’s in the 2.0 spec, 
you’re safe. However, in the 
real world you’re likely to come 
across EJB 1.1 applications, 
so be prepared to learn the 
differences. Especially if you’re 
the lucky one in charge of 
migrating the app to a 2.0- 
compliant server;) 
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How a bean actor becomes a bean entity 

Scenario: client wants to get the address of a 
specific CMP Customer entity, primary key #28. 




EJB 

biect 

#28 


Where the <&*%©! is 
number 28? The client is calling 
and I don't see anybody 
playing number 28! 


get/\ddress() 


context 


1 Client calls getAddress() on the stub for entity bean #28. The client got the stub from a 
previous call on the home stub (you’ll see exactly how the client got the stub in the first 
place, in a minute). 

2 The call is passed to the EJB object. 

3 The EJB object gets the call and panics, because there IS no entity bean for #28! 

The EJB object is the agent/bodyguard for #28, but he isn’t attached to a specific 
bean that’s playing #28. 
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How a bean actor becomes a bean entity 

The CMP bean comes out of the pool and prepares to play #28. 



I'll just wait 
while he learns how 
to be #28. 



EJB* 

object 

#28 




1 The Container ‘activates’ a bean by pulling it out of the pool and calling ejbActivate()_ 

2 The Container does a select on primary key #28 in the database, to get the real 
entity data to put into the bean (the data that will become the bean’s state). 

3 The Container loads the bean with the entity data from the database, and then calls 
ejbLoad() to tell the bean, “Hey bean, you’ve just been loaded.” 
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entity passiva tion/activa tion 


OK, time out! 

Does that picture say that ejbPassivate() 
is the bean's container callback for going back to 
the pool? Isn't that the opposite of how session 
beans work? With session beans, ejbActivate() 
has nothing to do with the pool, so what’s the 
deal? Are they just trying to make it as 
confusing as possible??? 



Passivation and Activation have a 
TOTALLY different meaning for entity 
beans! 

State/ess session beans go back to the pool 
without passivation (in other words, without getting 
an ejbPassivate() call). 

Stated/ session beans are passivated when 
the Container puts them to sleep (possibly 
serialization) to conserve resources between client 
method invocations. 

Entity beans aren’t passivated in the way that 
stateful session beans are, but entity beans DO 
get an ejbPassivate() call when they’re about to go 
back to the pool (and an ejbActivate() when they 
come out of the pool). 


The most important point is that, unlike session 
beans, passivated entity beans are still live 
objects on the heap! 


There’s no such thing as a bean sleeping in a 
pool. Stateless beans, entity beans, and message- 
driven beans all use pools. And those pools are for 
living, RAM-using, on-the-heap objects. 

Only stated// beans are put to sleep (called, 
confusingly, passivation), but this has nothing to 
do with a pool. 

So, yes, they’ve overloaded the word “passivation” 
just to make things really confusing for you and to 
help drive the need for more EJB books. (For which 
we thank them every single day.) 
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ejbPassivate(): the difference 
between session and entity beans 


Entity bean 



^j^Called when the bean has 

finished a business method (other 
than remove()) and is about 
to go back to the pool. In the 
passivated state, the bean has no 
identity—it's not representing any 
entity from the database! 


^Use it to release resources that 


you don’t want to waste while 
the bean is sitting in the pool, 
not running a business method. 
(Typically, the method is empty.) 


^j^The bean is NOT passivated 
in the session bean sense. In 
other words, the bean is not 
serialized or saved, so there is 
NO requirement that you null out 
references to non-Serializable 
objects. 


^(^The Container calls the bean’s 
ejbActivate() method when a 


bean is needed to service a 
business method from a client. 
The bean runs ejbActivate() 


before it runs the business 


method that triggered the 
activation. (This method is usually 
empty as well). 


Stateful session bean 









t %:〆 


^j^Called when the Container 
decides to conserve 「 6sou 「 c6s 
between business method 
invocations from the client. 


^j^Use it to release resources and 
to prepare the bean’s state for 
what might be serialization (null 
out non-Serializable references, 
etc). 

^(^The bean is “put to sleep” and is 
no longer taking up space on the 
heap. 


^(^The Container calls the bean’s 
ejbActivate() method when a 
client calls a business method 


on the EJB object. The bean 
runs ejbActivate() before it 
runs the business method that 
triggered the activation. 


Stateless session bean 


doeWi apply... sUeless 

⑽ s a 卜叫 passiva^d 


^(^Doesn’t apply! Stateless beans 


have a pool, but activation and 
passivation don’t play any part 
in it. Remember, stateless 
session beans will NEVER get an 
ejbActivate() or ejbPassivate() call. 
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The EwtityPcaw interface adds three new cowtaiwer 
callbacks (including two just for sywchroHizatiow) 


《 interface 》 

SessionBean 


setSessionContext( SessionContext sc) 


ejbPassivate() 

ej'bActivate() 

ejbRemove() 



《 interface 〉〉 


EntityBean 


set 


Entity 


Contexti 


EntityContext 


ec) 


ejbPassivate() \ 

ejbActivate() 

ejbRemove() ^ oy]ic ^ 



unsetEntityContext() 

ejbLoad() 

ejbStoreQ 


— 


The EntityBean interface adds three new methods (and the context setter 
changes to give the bean an EntityContext instead of a SessionContext). 
But... and this is an extremely large “but”", even the methods which are the 
same in both interfaces don’t behave the same. 

Of the four methods in SessionBean, only the context setter behaves the 
same as its counterpart in EntityBean. The other three, ejbPassivate(), 
ejbActivate(), and ejbRemove() have drastically different meanings. 

You’ll see. 

For now, just be ready to let go of your attachments to the meaning of 
activation, passivation, and removal. What those mean to an entity bean is 
nothing like what they mean to a session bean. 
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Evcw the methods that arc the same, 
don’t behave the same 


SessionBean interface 


EntityBean interface 


setSessionContextf Sess/or)Cor)te;rf sc) 

Container gives the bean a reference to its context. 

ejbPassivate() 

Called on a stateful session bean, when the bean 
is about to be serialized (or something like it). 

ejbActivatef) 

Called on a stateful session bean, when the bean 
is reactivated following passivation (might be 
deserialization). 


ejbRemove() 

Called on a stateful bean when the client calls 
remove(). Called on a stateless bean when the 
Container wants to reduce the size of the pool. 








“ 代朴 0 化 


EntityContext adds 
getPrimaryKeyO 


二 £ =r 

exposed only to entity beans. 


setEntityContext( EntityContext ec) 

Container gives the bean a reference to its context. 

ejbPassivate() 

Called when the bean is about to return to the 
pool, following a transaction. 

ejbActivatef) 

Called when the bean is taken out of the pool to 
service a client’s business method call. 

ejbRemove() 

Called when the client calls remove(), and wants 
to delete this entity from the database! 

unsetEntityContext() 

Called when the Container wants to reduce the 
size of the pool. 

ejbLoad() 

Called when the bean has been refreshed with 
data from the underlying persistent store. 

ejbStore() 

Called when the Container is about to update the 
database to reflect the state of the bean. 


you are here ► 311 





entity bean callbacks 


Put wait … there's more! Entity bea^s have wcw 
home container callbacks, too 


① 

Your home interface 



ere ate (String last, String first, String addr) • 
findByPrimaryKey(String key) 
findByCity(String city) 
updateAII(String cmd) 


Q) 


： eW ： 沙 C 十)， 

session bcarvs, W a ^ 5 

c^PostCvcatcO- 

You 一七⑽巧 Wc 

busmess method ^ ^ 

cjWW 〜 ctWNa 眯 c>. 

TV>C We，.etWs m 

戏 dcW ovav b 

wvl^'A'tcs)* 


ejbCreate(String last, String first, String addr) 
ejbPostCreate(String last, String first, String addr) 

ejbFindByPrimaryKey(String key) 
ejbFindByCity(String city) 
ejbHomeUpdateAII(String cmd) 

setEntityContext( EntityContext ec) 
ejbActivate() 
ejbPassivate() 
ejb Remove)) 

unsetEntityContext() 
ejbLoad() 
ejbStore() 

II business methods from the 
II component interface 


EntityBean interface 

(javax.ejb.EntityBean) 




setEntityContext(EntityContext ec) 

ejbActivatef) 

ejbPassivate() 

ejbRemove() 

unsetEntityContext() 

ejbLoad() 

ejbStore() 




al ’ —I 加伙 

^fcl/EK doh-taihcv dMadk ^ihod 
> youjr bcah class. Eh-tityBcah 

t dds ^ ^ methods ihsi 
^css.ohbcah ihic^a^c d\d^{ have. 


For any entity bean using container-managed persistence (CMP), you will always 
have at least seven container callbacks — all from the EntityBean interface 
implementation. You don’t have to have a create () method in your home, 
but if you do have create () methods, you must match each create () with not 
one but two methods: ejbCreate() and ejbPo^/Create (). If you have home 
business methods, you must write a matching ejbHome<methodName> 
method in the bean class. 

If you use bean-managed persistence (BMP), where you write your own 
database access code, you also must match each finder method with an 
ejbFind<whatever> method. Remember, the only method required in a 
home interface is findByPrimaryKey(). But in a CMP bean, you won’t put 
any finders in your bean class even though they’re in your home interface. 
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Writing a CMP cwtity beaw: 


make it abstract 

- -—— 


YES! I love CMP. The Container 
implements my finders, my getters, 
my setters, my select methods...and it writes 
all the database access code for the create, 
remove, load and store methods... just think 
how many flash mobs I can attend now 
that I don*t have to write all this bean 
code... 



Oh sure, you get to go have fun while *1* 
do all the real work. How come with each rev 
of the EJB spec, *1* end up doing more work 
and you end up doing less? That blows. Will you 
at least take some pictures of the flash mob next 
week at Barnes and Noble? At exactly 4:20 PM everyone 
shows up. At 4:24 everyone runs in and starts breathing 
hard and crouching behind bookshelves, like they're 
being chased by bad guys. At 4:29, they all run to the 
computer section, grab the nearest Head First book 
and shout, H I got it!’’, then they disperse. By 
4:31 - everyone is gone. 




Make your CMP entity bean class abstract 

You still have to implement the container callbacks from javax.ejb.EntityBean, 
and if you still have to write all your business methods (including those from 
the home), and if you have any create methods, you have to match those in the 
bean class as well. But that still leaves a pile of work for the Container to do, 
including the accessor methods for your persistent fields. For example, if your 
Customer table has a column for address, and you map that to a field in your 
bean class (so that clients can, for instance, call getAddress()), you don’t write 
the getters and setters for that field. In fact, you don’t even declare the field! With 
CMP, you create a virtual field, by defining getters and setters. In other words, 
the persistent field for address exists in your bean simply because there’s an abstract 
getter and setter for it. (Well... that’s not entirely true. There also has to be an entry 
in the deployment descriptor, but we’ll look at that in the next chapter). 
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entity bean class 


You put three kihds ofthmgs m your beaw class: 

① Things from the home interface 

■ For each create() method in the home, you must have 
a matching ejbCreate() and ejbPostCreate() method 
in the bean class. 

■ For each business method in the home, you must 
have a matching ejbHome<method> in the bean 
class. 


■ For CMP beans, you will NOT write matching finder 
methods. The Container will write them for you, based 
on info you put in the deployment descriptor. (We’ll go 
over all that in the next chapter.) 


«interface» 

CustomerHome 

create (String last, String first, String address) 
findByPrimaryKey(String key) 
find By City (String city) 
updateAII(String cmd) 


© Things from the component interface 

■ For each method in the component interface, you 
must have a matching concrete implementation in the 
bean class. 


〈〈 interface 》 

Customer 

getFirstName() 
setFirstName(String name) 
getLastName() 
setLastName(String name) 
getAddress() 
setAddress(String addr) 


(3) Things from the Entity Bean interface 

■ You must implement the EntityBean interface either 
directly or indirectly. So unless you have a superclass 
that implemented the methods, you’re responsible for 
writing concrete implementations in your bean class. 


〈〈 interface 〉〉 

EntityBean 

setEntityContext( EntityContext ec) 

ejbActivatef) 

ejbPassivate() 

ejbRemove() 

unsetEntityContext() 

ejbLoadf) 

ejbStore() 
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PLUS... (ok, thafs l^r things...) 

④ Virtual persistent fields 

■ For each persistent field, provide an abstract getter and setter 



^Virtual persistent fields 9 are for the 
values that map to columns in the 
database. They represent the entity’s 
persistent state. In your bean class 
code, they exist only as abstract 
getters and setters 


几 is bc^h four 


First: John 
r Last: Mayer 
PK: 22 
Address: 1 Derland St 


First 

Last 

PK "V 

Address 

John 

Mayer 

22 

1 Derland St. 

Fran 

Healy 

16 

200 Bar St. 

Bela 

Fleck 

5 

25 Pick Lane 
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virtual fields 


Virtual fields are NOT instance variables! 


public abstract class CustomerBeanCMP implements EntityBean { 


public String ejbCreate(String last. String first. String addr) { 

this.setLast (last); 
this . setFirst (first); 
this.setPK(makePK()); 
this.setAddress(addr); 
return null; 


private EntityContext context; 


the 




liable is 


\r 


public 

public 

public 

public 

public 

public 

public 

public 


abstract String getLast(); 
abstract void setLast(String last); 
abstract String getFirst(); 
abstract void setFirst (String first); 
abstract String getCustAddress(); 
abstract void setCustAddress(String addr) 
abstract String getPK(); 
abstract void setPK(String pk); 


T..C a. f 

T ^ Ve : J '一如 


public String getLastName() { 

return this.getLast (); 

} 

public void setLastName(String name) { 
this.setLast(name); 

} 

public String getFirstName() { 

return this.getFirst (); 

} 

public void setFirstName(String name) { 
this.setFirst(name); 

} 

public String getAddress() { 

return this.getCustAddress(); 

} 

public void setAddress(String addr) { 
this.setCustAddress(addr); 


// more methods from EntityBean 
// and the home interface 


ih youv- 


L ^ - e , ode ihah whai you see w 
X=X；^::: ab — 七 
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t^arpen your pencil 

Using the ii 


Using the interfaces below, write a legal bean class. You don’t have 
to write the actual business logic, but at least list all the methods 
that you have to write in the class, with their correct declarations. 


《 interface 〉〉 

ProductHome 


《 interface 〉〉 

Product 


〈〈 interface 〉〉 

EntityBean 

ere ate (String description, String cat, double price, String ID) 


getCategoryf) 


setEntityContext( EntityContext ec) 

findByPrimaryKey(String key) 


getlD() 


ejbActivate() 

findByCategory(String category) 


getDescription() 


ejbPassivate() 

getLowStockltems() 


setDescription() 


ejbRemove() 



getPrice() 


unsetEntityContext() 


set Price () 


ejbLoad() 

Write the class here in the space below; don’t 



ejbStore() 

worry about import statements: 




you are here ► 


317 











CustomerBeanCMP code 


Complete code for the CustomerBeanCMP class 

(note: it’s not annotated, because that’s YOUR job in the Sharpen exercise on the next page) 


package headfirst; 
import javax.ejb.*; 


public abstract class CustomerBeanCMP implements EntityBean { 

private EntityContext context; 

public String ejbCreate(String last, String first, String addr) { 

this.setLast(last); 
this . setFirst (first); 
this.setPK(makePK()); 
this.setAddress(addr); 
return null; 

} 

public String getLastName() { 

return this.getLast(); 

} 

public void setLastName(String name) { 
this.setLast(name); 

} 

public String getFirstName() { 

return this.getFirst(); 

} 

public void setFirstName(String name) { 
this.setFirst(name); 

} 

public String getAddress() { 

return this.getCustAddress(); 

} 

public void setAddress(String addr) { 
this.setCustAddress(addr); 

} 

public void setEntityContext(EntityContext ctx) { 
context = ctx; 
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public 

public 

public 

public 

public 

public 

public 

public 


abstract 

abstract 

abstract 

abstract 

abstract 

abstract 

abstract 

abstract 


String getLast (); 

void setLast(String last); 

String getFirst (); 

void setFirst (String first); 

String getCustAddress(); 

void setCustAddress(String addr); 

String getPK(); 

void setPK(String pk); 


public void unsetEntityContext() 


public 

public 

public 

public 

public 


void ejbLoad() { } 

void ejbStore() { } 

void ejbActivate() { 

void ejbPassivate() 
void ejbRemove() { } 


private String makePK() { 

int rand = (int) (Math.random() 
return rand; 


* 42 ); 


娜?七二峰以 

: 永 ㈣ S 口丄 —㈣ 


use a 

ov a 

sort , 饮 





① Mark each method in the CustomerBeanCMP class with one of the following four 
symbols: 

H C EB \/F 


based on the reason for that method’s existence in the class. For example, the 
ejbCreate() method is required because there’s a matching create。in the home, 
so mark an H next to the ejbCreateQ method. 


② 


Put a check mark next to those methods that the compiler cares about. In other 
words, if you left a method out and the compiler would complain with an error, then 


mark that method with a 


V 


③ Annotate the code yourself with any other details you can think of. For this exercise 
(but not the previous two), do as much as you can on your own, then turn back to 
earlier pages in this chapter and see if you can add or change anything. 
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Entity bean instance lifecycle 


instance throws system exception 
does not exi^t (unchecked, uncaught) 


constructor 

setEntityContext() 


unsetEntityContext() 


e jbHome<methoc/>() 
(home business methods) 


ejbCreate<method>() 
ejbPostCreate<method>() 


ejbStoreQ 


^ f 



business method 
(component interface) 


ejb5e/ect<method>() 

(called from a business method) 



Let's see here... by my 
calculations it should take me 
approximately 2.3 years to memorize 
this lifecycle diagram, so that would 
mean I can schedule the exam for 
sometime in the year 2007 … 




320 Chapter 6 













entity bean synchronization 



ejbFind<method>() 
ejb5elect<method>() 


ejbRemoveQ 


Moving from does not exist 
to pooled 

constructor 
setEntityContext() 
note ： no createQ! 


e jbHome<method>() 
(home business methods) 


ejbCreate<method>() 
ejbPostCreate<method>() 


ejbStoreQ 





ejbLoadQ 


business method 
(component interface) 


ejb5elect<method>() 

(called from a business method) 


Moving from pooled to 
method-ready 

ejbCreateO / ejbPostCreateO 
OR 

ejbActivate() 

(The Container does NOT call 
ejbActivate() if it calls ejbCreate()) 


Moving from method ready 
to pooled 

0 jbPassivate() 

OR 

ejbRemoveO 

(Never both! A bean doing an 
ejbRemoveO will NOT be passivated 
before going back to the pool!) 


does f 


constructor 

setEntityCon+ext() 




ist 


instance throws system exception 
(unchecked, uncaught) 


unsetEnti+yContext() 


e jbHome<method>() 
(home business methods) 


ejbCreate<method>() 
ejbPostCreate<method>() 


ejbStoreQ 



ejbFind<method>() 
ejb5elect<metbiod>() 


ejbRemoveQ 


ejbLoadQ 


business method 
(component interface) 


ejb5elect<method>() 

(called from a business method) 


Entity bean instance transitions 


Sets ； UM 

at stuW. 


does not exist 


instance throws system exception 
(unchecked, uncaught) 


constructor 

setEnti+yContex+() 


unse+Enti+yContext() 



oaidqfa 


ejbActivateo 
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entity state transitions 


ejbFind<method>() 
_J e jb5elect<method>() 


ejbRemoveQ 


Moving to does not exist 


unsetEntityContext() 

OR 

instance throws a system exception 


e jbHome<method>() 
(home business methods) 


ejbCreate<method>() 
ejbPostCreate<method>() 


Entity bean instance transitions 


does not exist 


instance throws system exception 
(unchecked, uncaught) 


a 


constructor 

se+En+ityContex+Q 


unsetEntityContextQ 


ejbStoreQ 



ejbLoadQ 


business method 
(component interface) 


ejb5elect<method>() 

(colled from a business method) 


f]i©reiareriP 

Dumb Questions 


How come there is a label for 
ejbSelect<method > (whatever THAT is) in both the 
pooled state and the method-ready state. How can 
you run those methods in both? 


A ： 


We’ll get to ejbSelect methods a bit later, but 
for now, think of them as private methods in the bean 
(in other words, called not by the client, but only 
by the bean’s own methods) that do selects on the 
database.They’re used only for CMP beans, and can 
be a huge convenience, since they’re implemented for 
you by the Container.The reason they’re in both 


places is because it depends on which interface the 
client uses to call the method that in turn calls a select 
method. So, if a client calls a home business method, 
and the home method calls an ejbSelect<method>, 
the bean stays in the pool to run the method. But 
if the select method is called from a method in the 
bean’s component interface, that means the method 
is running on a specific entity, say, Frank Foof #56, so 
the bean is in the method-ready state. 



()34-D>SSDQ_clf3 


ejbActiv D teo 
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^JiereiSireJiP 

Dumb Questions 

It looks like there are TWO ways to move 
to the method-ready state: either the client 
calls a createO method or the Container calls 
ejbActivate(). So does this mean that you can’t 
count on ejbActivateO being called each time you 
leave the pool? 

A- 

Jr \ m That’s right. A bean can move to the method- 
ready state by ONLY those two paths (creation or 
activation) but never both at the same time. So, if you 
have a design that acquires resources in ejbActivateO, 
so that they’ll always be available while the bean is 
servicing a business method, you better grab them 
in ejbCreateO (or ejbPostCreateO — you’ll see the 
difference in a few minutes). 

In the real world, it's much less common in EJB 2.0 
to use ejbActivateO for much of anything. We’ll talk 
more about this both in this chapter and the last 
chapter (patterns and performance), but the short 
version is this: it’s usually more efficient to acquire 
and release scarce resources just within the business 
methods that need them.That way, you’re not 
hanging on to them (preventing other beans from 
having access) while your bean is active (i.e. not in 
the pool), but not actively running a method. Yes, that 
means you have some additional overhead in each 
business method, as opposed to grabbing the thing 
once in ejbActivateO, but in many cases the overhead 
of grabbing the resource is minor compared to the 
scalability cost of holding resources (we’re thinking... 
database connections from the pool) open longer 
than you need to access those resources. 

Bottom line: You’ll probably find yourself leaving 
ejbActivateO empty, in so you won’t have to worry 
about missing it when you come out of the pool via 
an ejbCreateO call. 


e^irpen your pencil 


For the exam, you have to know exactly 
which container callback methods are in the 
EntityBean interface, so you need to memorize 
these. The tricky part is that some of them 
have the same names, but completely different 
behavior than their session bean counterparts in 
the SessionBean interface. DO NOT LOOK ON 
THE OPPOSITE PAGE! 

1 ■ The client calls this method to tell the 
Container that he (the client) is done using the 
bean’s EJB object reference: 


2. This method is called when the bean goes 
back to the pool, after an entity is deleted from 
the database: 


3. This method is called immediately after the 
bean’s constructor runs: 


4. This method is called on the bean when the 
bean is in the pool, and the client invokes a 
business method on the component interface. 
(We’re looking for the first method called in that 
scenario) 
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entity lifecycle activity 


e^^rpen your pencil 


Fill in the missing methods. Don’t worry if you don’t get the 
name exactly right; just try to work out what happens at 
the transitions in the entity bean state diagram. 


M _ instance throws system exception 

does not exist (unchecked, uncaught) 



You have to Know every detail of this lifecycle! 

earlier, are where the metho s in a special care with: 

create (make a new bean ■ ， Hplete an entity in the database) 

Ln 9 oes , . 0. 0, ,e P ooO 
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So how W the client get a reference to the 
WP object for * 28 ? 


When a client wants to call a business method on a specific entity (in other 
words, an entity with a unique primary key, like Lee Loo #28), the client first 
needs a reference to that entity’s EJB object. 

For an entity bean, remember, there are three ways that can happen: 

① Client calls a finder on the home 

customerHome .findByPrimaryKey (、'2 8 〃）； 

② Client calls create on the home (to insert #28 for the first time) 

customerHome . create (''Loo", ''Lee",''2 8’’，''54 Bar Circle"); 

③ Client calls a home business method that returns a 
reference to the bean’s component interface 

customerHome .getCustomerByStreet (''Bar Circle"); 


We’ll talk about each stage of the bean’s lifecycle for finders, creates, and 
home business methods. But first — each of these assumes that the bean 
instance already exists in the pool. But how does the bean get there in the 
first place? 


does not exist 


constructor 

se+EntityCon+ext() 



Bc-fovc dieh 七 use 3 (or 

— tvcaiioh, fmdevs, business 

rwctiiods, tit-, 七 he Coh*ta*mc\r V»as -fco make 
a how bedh -fov -the pool. 

CONSTRUCTION is^-t tied *fco wtrty 
CREATION- 


Bu 七 ^\rca*tioh, -fov By\ Chtrty medhs a 
k\c>m ctvt’rty is *mscv-tcd m*to dd~tdbase- 
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CMP Entity bean construction 

Scenario: Container wants to make a new bean instance for the pool 


1 Container makes a new EntityContext 

2 Container makes a new instance of the 
bean class (bean’s constructor runs) 



3 Container calls setEntityContext() on the 
bean. This is the ONLY time in a bean 
instance’s life that it will get this call. 

4 Container puts the bean (which now has a 
context) in the pool. 

Notice: create() was never called! A create() 
method is only for inserting a new entity into 
the database, and has nothing to do with the 
bean instance’s creation! 
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things you caw do during entity cowstroctiow: 

timeline 


constructor 

Use your EntityContext to: 

□ get a reference to your home 

□ get a reference to your EJB object 

□ get security information about the clienl 

□ force a 
beanj 

Tsaction has already 
^efto rollback (CMT beans) 

□ get a transaction reference, and call 
methods on it (BMT beans) 



setEntityContext() 

Use your EntityContext to: 

□ get a reference to your home 

□ get a reference to your EJB object 

□ get security information about the client 

□ force a transaction to rollback (CMT 
beans) 

□ find out if the transaction has already 
been set to rollback (CMT beans) 

□ get a transaction reference, and call 
methods on it (BMT beans) 


Access: 

□ your special JNDI environment 

□ another bean’s methods 

□ a resource manager (like a database) 


Access: 

Stf your special JNDI environment 

□ another bean’s methods 

□ a resource manager (like a database) 



What to put in the constructor 

We know it’s painfully obvious by now... NOTHING. 

Unless you’re forced to, don’t even put a constructor in your code at all, and just use 
the compiler-generated default constructor. 

Whatever you do, be SURE you have a public no-arg constructor in your class! 

public Customer() { } 


What to put in the setEntityContext() method 

Assign the context to an instance variable. Remember, you get only ONE chance 
to save it. You might not always need to use a session context, but you’ll probably 
need an entity context. Besides, your context is gonna stay alive whether you keep 
a reference to it or not, so the only memory you save if you don’t keep it is for the 
reference variable, not the object itself. 

public void setEntityContext(EntityContext ctx) { 
context = ctx; 
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CMP Entity bean creation 


Scenario: client wants to create a new entity in the database (remember, the 
Container made the bean instance and the context earlier, and put them in the pool) 






1 Client calls createf Billy Bob”）on the home stub 

2 The createf Billy Bob”) method invocation is passed to the home object. 

3 A bean is pulled out of the pool to do the creation 

4 Container calls ejbCreatefBilly Bob”）on the bean instance 


cr 匕 ’ 


bean 


4 


e 产仪 C— % 


bean-2 





EJB 

object 

#55 




5 Container inserts a new entity (row) in the database, for primary key #55 


. ' I context^ 
i ...... #55 


6 Container gives the EJB object and EntityContext the primary key value (#55). 

7 Container calls ejbPostCreatefBilly Bob”）on the bean, to give the bean a chance to finish initializing itself 

8 The home returns the EJB object stub to the client 
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Creating a new entity 
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CMP entity bean 


二 client 

V 



H) 






create() 


ejbCreate() 


database insert 


new 


ejbPostCreate() 


business method 


I 

, i V>ed^ ms-ta^C) 

cSi s A s ?ooU 

I 


business method 



i 


Whoa! This is quite different from session 
bean creation … 

The Container calls ejbCreate() on a session bean 
instance only once, at the beginning of the bean’s 
life. That’s one big difference between session and 
entity beans — entity beans can run ejbCreate() 
over and over, like a business method. In fact, 
that’s the best way to think of it... as just another 
home business method, as though it were named 
ejblnsert() (which, in our humble opinion, it 
should have been named, but once again, they 
forgot to ask us). 


But the second difference between entity and 
session bean ejbCreate() methods is the order in 
which the EJB object is created. When an entity 
bean runs ejbCreate() there’s no EJB object!! 
Yikes! That means the bean has no way to get a 
reference to its bodyguard. In other words, an 
entity bean cannot use the ejbCreate() method to, 
say, get a reference to its own EJB object and pass 
that reference to someone else. Remember, a bean 
can’t pass a reference to itself, ever! When a bean 
wants to pass a reference to itself, it must pass a 
reference to its own EJB object. But it can’t do that 
in ejbCreate(), because it’s too early! 
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CMP bean creation 


CMP Entity bean creation 



OK, in my ejbCreate() 
method i’ll use those args 
from the client to set my own 
persistent state (last name, first 
name, primary key, etc.) 


Great! Now I can 
look at your persistent field 
state, and use the data to 
create the new customer in 
the database 




Before 


After 


Last 

First 

PKey 

Frankie 

Foof 

99 

Bryan 

Boof 

314 

Billy 

Bob 

55 


Last 

First 

PKey 

Frankie 

Foof 

99 

Bryan 

Boof 

314 


OK bean, if you need 
to finish up your creation, 

I*m done inserting the row and 
making the EJB object, so run your 
ejbPostCreateO, and here's the 
original create args, just in 
cr \ case you forgot... 


O 




Thanks! Now that 
I’m in ejbPostCreateO, I know 
that my EJB object is ready, and 
I can get a reference to it from my 
context. I need to pass a reference to 
myself (which means a reference to 
my bodyguard) out to another bean, 
so I REALLY needed a second 
chance to finish my creation... 
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Implement your ejbCreate() methods 


What to put in ejbCreate() 

Put your entity initialization code here! This means setting values for your persistent 
fields... the fields that map to columns in the database row that’s about to be inserted. 

Notice we aren’t saying, “put your object initialization code here."” With session beans, we told 
you to treat the ejbCreate() kind of like a constructor for the bean. But with entity beans, it’s differ¬ 
ent because the instance was initialized a long time ago (when its setEntityContext() method was 
called). 

So, ejbCreate() is about initializing the bean as this new entity the bean will now represent. For 
a CMP bean, this means the client has handed you arguments representing the data to insert 
into the database. The Container will look at the state of your persistent fields, once ejbCreate() 
returns, and use those fields to make the new row in the database. 

If you do nothing else in ejbCreate(), you must make a primary key for this entity! That’s your 
most important job. You might make the key based on arguments to the create method. You 
might make the key based on a key-generating algorithm. You might have a key server that you 
go to for the next key. Whatever it is, you must come up with the key, and assign it to your primary 
key field. When ejbCreate(), the Container looks at the state of your persistent fields, and uses 
that data to make the new row. 

Warning! Remember, the Container calls your ejbCreate() before it can make the EJB object, so 
you can’t use ejbCreate() to get a reference to yourself! (i.e. a reference to your bodyguard/EJB 
object). You’ll have to wait until ejbPostCreate() before you can ask your context for a reference 
to your own component interface. You also can’t use ejbCreate() to access your own persistent 
relationships; you have to wait until ejbPostCreate() (but we’ll cover all that in the next chapter). 



卜 63SC, 

叫， so 七 





rt m 



public String ejbCreate (String last, 

// assign args to persistent fields 
this.setLastName(last); 
this . setFirstName (first); 


String first) { 



0 广 ^eaicO domplcies, 


// set a primary key 

this.setPrimaryKey(this.makeKey()); 

return null; 


vow. 


s up with THAT? 
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Object identity: the primary key 

Every entity MUST have a unique identity. The Container will never let you 
get away with having two or more entities with the same primary key. And as 
of EJB 2.0, coming up with that primary key is still your job. The Container 
won’t do it (at least not according to the specification). 



I'm not gonna do it. YOU 
have to come up with the 
primary key. I don’t know what 
your business logic is, and I’m 
not gonna be a primary-key 
generator for you. 



' 


And don’t expect me to 
do it either, if you're using 
CMP. You have to come up with 
the primary key BEFORE the 
Container tries to insert the new 


row. 



With CMP, you’re still responsible for the primary key. That doesn’t mean you 
won’t use a primary key service of some kind. Maybe you have a service that 
automatically allocates a big block of primary keys from the database, and 
then hands them out as needed. Or you might have some type of unique 
identifier algorithm that makes unique keys for you. Or maybe you’re using 
the customer’s social security number or account number or... that’s up to 
you to decide. 

And the way you tell the Container what value the about-to-be-created entity 
should have is through the value of one or more of your persistent fields. 


If you have just one field as your primary key, and it maps directly to a 
column in the database, you’re set. But if you need more than one value to 
uniquely identify an entity (like, maybe it takes a combination of name and 
date), you can use a compound key that uses two or more of your container- 
managed persistent fields. 
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Rules for ejbCreate() 

■ You must implement the ejbCreate<method> to match each 
create<method> in the home interface. 

■ The method name must begin with the prefix “ejbCreate”. 

■ The method must be declared public, and must not be declared static 
or final. 

■ The declared return type must be the entity bean’s primary key type, 
even though you will return null from the method . 

■ The method arguments must be the same as the arguments of the 
matching create<method>. 

■ You may declare a throws clause with CreateException, or any 
arbitrary application (checked) exception that you like, as long as it 
was also declared in the home interface, but you must NOT declare a 
RemoteException. 

Rules for Primary Keys 

■ A primary key class must be Serializable and public. 

■ You can use a single persistent field from your bean class as your 
primary key, by identifying both the field name and the class type in 
the DD. 

■ If you need two or more persistent fields to uniquely identify your 
entity, make a custom compound primary key class. 

■ A compound key class must be made up of fields that are defined as 
persistent fields in the bean class. The fields in the bean class must 
have public accessor methods. 


By the end of ejbCreate() 
you MUST Have a valid 
primary l^ey assigned to the 
CMP field that you’ve the 
told the Container is your 
primary fey field. 

If you use a compoimdl^ey, 
^ien ALL ilie fields that 
makeup that fey must Kave 
valid values. 

If at 也 e end of ejbCreate() 
your primary fey is null, 
the Container won't do the 
create! 




How come I can't have the database come up with the primary 


key? That's how we usually do it. Are you telling me the Container can't 


do that? 


Yes, that’s what we’re telling you.The contract you have with the 
Container says that by the time ejbCreateO is done, you’ve done whatever 
you had to do to make a valid primary key. You might have a server that 
lets you say,"Let the database come up with the key when you do the 
insert ’； but there’s no guarantee in the spec, and you can’t assume that 
all EJB vendors support this. Maybe some day in the future, there will be 
a deployment-independent way to say,"Use auto-generated key” in the de¬ 
ployment descriptor. But today is not that day. And EJB 2.0 is not that spec. 
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Implement your ejbPostCreateQ methods 

What to put in ejbPostCreate() 

Finish your initialization code here! Now you can see why entity beans need 
an ejbPostCreate()—because ejbCreate() is too early for some things. The 
two most important reasons for ejbPostCreate() are that you can use it to get 
a reference to your own EJB object, and you must use it for accessing your 
container-managed relationships (CMR). (We’ll look at CMR in the next chapter.) 

Think of ejbPostCreate() as the other half of your ejbCreate(), with some Really 
Important Things happening in the middle. It’s your second (and last) chance to 
finish your initialization, if you need to do things as part of creating the new entity 
that depend on having access to your EJB object (or something else that can 
happen only in ejbPostCreate(), and not in ejbCreate(). 

Well revisit ejbPostCreate() in the next chapter, when we look at CMR. 


Rules for ejbPostCreate() 

■ You must implement the ejbPostCreate<method> to match each create<method> 
in the home interface. 

■ The method name must begin with the prefix “ejbPostCreate”. 

■ The method must be declared public, and must not be declared static or final. 

■ The declared return type must be void! 

■ The method arguments must be the same as the matching ejbCreate<method>. 

■ You may declare a throws clause with CreateException, or any arbitrary applica¬ 
tion (checked) exception that you like, as long as it was also declared in the home 
interface, but you must NOT declare a RemoteException. 
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All three have the same args ， 
but different return types! 


Home interface 
create<method> 


public Customer create(String last. String first)throws 

今 CreateException,RemoteException) 


Bean class 
ejbCreate<method> 






s 


public String ejbCreate(String last. String first) {... 


Bean class 

ejbPostCreate<method> 





public void ejbPostCreate(String last. String first){...} 

unless ^七私 c? W 心广巧 C 於 

Think about the three methods above, and how they’re related to one another. Think about 
what they’re each responsible for. Now answer these two questions: 

1. Why are the return types declared like this? In other words, explain why each of the three 
different return types is what it is... 



2. Why do both ejbCreate<method> and ejbPostCreate<method> have the same arguments? 
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I'm having a hard 
time coming up with a 
reason why a bean would 
need a reference to its 
own EJB object... 



Imagine you input a new Customer 
in the database. Maybe your 
business logic says, H When you 
make a new Customer, tell the marketing 
department by passing a reference to the 
new Customer entity bean out to the 
CustomerRegistration bean. w 




^ 0 ^ [ £0 


Think about it college boy. 

First off, ifs against Bean Law. The 
EJB spec forbids passing 'this 1 as 
an argument from bean code. NOBODY 
is supposed to get a direct reference to 
the bean except the container!! Geez... if 
somebody DID get a reference to the 
bean, they could just call methods on 
it and skip all my services! 
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Oh, I get it... if I want 
to pass a reference to the 
bean, I pass a reference to the 
beans bodyguard instead. Like 
passing the EJB object’s 
business card, instead of the 
bean's. Right? 


If you want the bean, you 
gotta go through me. And you 
do NOT want to mess with me. I’ve 
watched the Matrix, like, 17 times, 
and I’ve been taking Pilates for, 
like, 2 years. 



^4 


鵪 


It’s like this, if I’m a bean I 
say to a method of someone 
else, H Here's a card you can use 
to reach me. But don’t call me, call 
my bodyguard, and here's his 
contact information … ,， 




Instead of : 厂 _ 

doStuff(this); 


Use: 



doStuff(myContext.getEJBObj ect()) 
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things you can do during entity creation: 


timeline 



ejbCreate() 

Use your EntityContext to: 

□ get a reference to your home 

□ get a reference to your EJB object 

□ get your primary key 

_ get security information about the client 

1^1 force a transaction to rollback (CMT 
beans) 

Hf find out if the transaction has already 
been set to rollback (CMT beans) 

□ get a transaction reference, and call 
methods on it (BMT beans only, so 
entities can’t use this) 

Access: 

^ your special JNDI environment 
another bean’s methods 
a resource manager (like a database) 

l eUe ^ e ^ EJB 

yr ^ i c ^ 

IZ V L C ^ dc ^ ^ ^ 

域 ㈣ 


0\r\dc 
^ill look 


ejbPostCreate() 

Use your EntityContext to: 

□ get a reference to your home 

G ’get a reference to your EJB object 

[3 get your primary key 

謹 get security information about the client 

fif force a transaction to rollback (CMT 
beans) 

Hf find out if the transaction has already 
been set to rollback (CMT beans) 

□ get a transaction reference, and call 
methods on it (BMT beans only, so 
entities can’t use this) 

Access: 

^ your special JNDI environment 
another bean’s methods 

8^ a resource manager (like a database) 
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CMP Entity finder 

Scenario: client wants to get a reference to an existing entity bean 



bPindByPrimary^vC ^ 


1 Client calls findByPrimaryKey (“ 28”）on the home reference 

2 The finder method is passed to the home object 

3 A bean is selected from the pool to run the ejbFindByPrimaryKey (“ 28”) method 

4 The bean does a select on the database, to verify that an entity with primary key #28 exists 



5 The bean returns the primary key (#28) to the home, which means the entity exists in the database 


6 The Container makes (or finds) an EJB object for #28 


7 The Container returns the EJB object stub for #28 

Note: if the bean had not found a matching entity for primary key #28, the client would get an 
ObjectNotFoundException (subclass of FinderException) 
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Finding an existing entity 


CMP entity bean 




find<method>(args) 


H) 


ejbFind<method>(args) 






database search 


business method 
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CMP Entity bean finders 


Hey bean, 
run this ejbFind 
method, and here is 
the client arg 、 '72 〃 


o 


J 


Um ; aren't you forgetting that I’m a 
CMP bean? I don't have these methods 
in my bean class. Although come to think 
of it, I’m a concrete implementation that 
the Container—I mean YOU—made from 
my abstract class, so maybe I DO have the 
methods after all but I just didn’t 
realize it and... 


Relax. And you re right... I’m 
the one that implemented the CMP 
finder methods, so well show it this way, 
even though it is you that conceptually 
does the work. I guess in the end 
it doesn’t matter as long as it 
\ happens. 



o 


Now that I have 
verified that this entity 
exists, I can make the 
EJB object, if it doesn't 
already exist. 


I’ 


j search for pk #72 




Last 

First 

PKey 

Poly 

Morphism 

72 

Dewey 

Cheatem 

900 




OK client, here's 
your EJB object 
reference for #72. 

You can use it to call 
business methods on Poly 
Morphism, #72. 


.0 


J 
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YOU don’t implement the Finder methods! 


You implement — ^ 

(create and home business methods) 


Container implements < — ^ 

(finder methods) 


〈〈 interface 》 

CustomerHome 

create (String last, String first) 
updateAII(String cmd) 

findByPrimaryKeyfString key) 
findByCity(String city) 


Just don’t write 'em. For a CMP bean, don’t put 
anything in your class about the finder methods. 
You will implement your create and home 
business methods, but as far as your own bean 
class — the one that you write — goes, there are no 
finder methods. 

You do declare them in the home interface, 
of course, including the mandatory 
findByPrimaryKey (), but you don’t write any 
other Java code related to your finders. 

The Container looks in your home interface and 
your deployment descriptor to figure out what to 
do with the finder methods, and the Container 
writes all the code for them. You’ll never see it. 


Don't put anything in 
your bean class about the 
finders. TKe Container 
implements your finder 

methods, using the hme 
interface and your 
deployment descriptor to 
figure out whi to do. 

Your bean class must 

not even MENTION ike 

fender methods. 


CustomerBean 


ejbCreate(String last, String first) 
ejbPostCreate(String last, String first) 
ejbHomeUpdateAII(String cmd) 
ejbFina^^rhmrfyKeyfString key) 
ejbFind^fufy^tring city) 


setEntityContext( EntityContext ec) 

ejbActivate() 

ejbPassivate() 

ejbRemove() 

unsetEntityContext() 

ejbLoad() 

ejbStore() 

II business methods from the 
II component interface 
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Hmmmm... I noticed that the bean 
didn’t come out of the pool. But whafs 
REALLY weird is that now there's an EJB object 
for #72, but there's no entity bean playing the 
part of #72. The bean never got loaded up with 
the entity data from the database, so what 
happens if the client calls a business method 
like getAddressQ ??? 



Why should I waste a bean's 
time by loading it up with the 
data, when the client might not 
ever call a business method on 
that EJB object reference? 



I hear what you're saying, but 
come on... aren't the chances 
pretty good that the client IS 
gonna call a business method 
on the bean? They went to the 
trouble of finding it... 



You just always have to 
know the truth... OK, you 
got me on this one. Yes, it IS likely 
the client will call a business method on the 
entity, so it might seem more efficient to have 
the bean ready. But even if I DID load the 
data into the bean during the finder method, 

I’d still have to reload it anyway. Why? 

Because by the time the client gets 
around to calling the business method, 
the bean's state might be stale! 
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I’m not following... 
what do you mean by 
stale? How can the bean become 
stale, if nobody else can get 
to the bean's data? How 
could anybody change the 
entity? 



Think about it. The entity, Poly Morphism, 
lives in the database (a row in a table). Sure, 
we can hand out references to the EJB object 
for this entity, BUT... the entity BEAN isn't the 
only way to get to the database! So while the client is 
waiting to call a method, for all we know someone else 
could have updated Polys record in the database. 

If that were to happen, then when the client calls 
a method on the Poly entity bean, the bean 
returns old, wrong information. 



Ok, now I get it... if the bean were 
to be loaded up with data during the 
finder method, then by the time the 
client calls a business method on it, the 
underlying entity data in the database 
might have changed. 



Yes! I'm gonna have to load 
the data in again as soon as the 
client calls a business method, just to 
make sure that the bean is refreshed 
with the most current data, so there’s 
no point in loading it in during the 
finder. It would just be a waste 
of resources. 
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CMP Home Business Methods 

Scenario: client wants to call a business method in the home 



1 Client calls updateAII() on home reference. 

2 The updateAII() method is passed to the home object. 

3 A bean is selected from the pool to run the ejbllpdateAII() method. 




1 Without leaving the pool, the bean runs the home method, probably calling on a Container- 
implemented select<method> to access the database. 

2 The bean returns from the method (possibly returning data). 

3 The Container passes the return value back to the client. 
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Client invokes a Home Business Method 

CMP entity bean 



client 



home business method 


-► 


EJB 

object 




home business method 







involved/ 


database access via a 
Container-implemented 
select method 


What to put in a home business method 


As you write your code, remember that an entity bean stays in the pool when it runs a 
home business method. Put code in your home business methods that apply to the underlying 
database—for a group of entities rather than one specific entity—and that don’t return the bean’s 
component interface (the way finders and create methods must). 

public Collection ejbHomeDisplayAll() { 

// do a select on the database, using a container-implemented 
// select method (next chapter), then return an ArrayList of Strings 


Rules for home business methods 


■ You must have an ejbHome<method> method for every home <method> in the home interface. 

■ The name must begin with the prefix “ejbHome”，followed by the name of the home <method>, but 
with the first letter of the method capitalized. For example, updateAII() in the home interface will be 
ejbHomeUpdateAII() in the bean class. 

■ The method must be declared public and NOT static. 

■ If the home interface is Remote, the arguments and return values must be legal types for RMI-IIOP. 

■ You may declare a throws clause with your own application (checked) exceptions, as long as the 
exceptions were also declared in the home interface. 

■ Even if your life depends on it, you must NOT declare a RemoteException. 
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莰 eaH thmgs you om do m home business methods 


Use your EntityContext to: 

□ get a reference to your home 

□ get a reference to your EJB object 

□ get your primary key 

M get security information about the client 

_ force a transaction to rollback (CMT 
beans) 

试 find out if the transaction has already 
been set to rollback (CMT beans) 

□ get a transaction reference, and call 
methods on it (BMT beans only, so 
entities can’t use this) 


Access: 


嘁 




your special JNDI environment 
another bean’s methods 
a resource manager (like a database) 


do bctavAsc 

VOVA ^ 

oJt m f 

6 ovavsC, r.0 — ” 咐 
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Starting a business method (in a transaction) 

Scenario: client wants to get the address of a specific CMP Customer entity 



r EJB 

object 

#28 


1 Client calls getAddress() on the stub for entity bean #28. 


2 The call is passed to the EJB object. 

3 The EJB object gets the call and panics, because there IS no entity bean for #28! 

4 The Container sees that this method needs a transaction, so the Container starts one, 
then pulls a bean from the pool, and calls ejbActivate() on the bean 



ejbLoadQ 


SELECT 


stub 

#28 


client 


The Container tells the database to lock entity #28 in the database. The 
Container then does a SELECT on the entity’s data. 


Tell database 
to lock row 


2 The Container populates the entity bean’s persistent fields with the real entity data. 

3 The Container calls ejbLoad() on the bean, to tell the bean, “You’ve just been loaded.” 
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Completing a business method (and a transaction) 

Scenario: bean completes a business method that ends a transaction 



fEJB 

object 

#28 


1 The getAddressQ method is passed to the bean (finally!) 


return 


2 The bean returns from the method 

3/4 The EJB object sends the return back to the client 



The Container calls ejbStore() to tell the bean, “I’m about to take your persistent 
field state and update the database, so be sure your state is ready.” 


Transaction Ends 
(unlock row) 


2 The real entity is updated in the database. 

3 The Container commits the transaction and tells the database to unlock the entity. 
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being an entity bean 


Being John Entity Bean 


It all starts when the 
client calls a business 
method on an EJB object 
for John Malcom. The EJB 
object freaks out because 
there's a call, but no entity 
bean to run the method. 


So the 

Container phones 
back to the pool 
and says, u We need 
a bean out here 
to service a client 
method..’’ 





I might not be 

completely ready when I come 
out of the pool, so the Container 
calls my ejbActivate() method. It’s 
actually a pretty useless method, so 
I almost never do anything there. But I 
suppose I might reacquire a Socket or 
something I don’t want to hang on to 
while 'between projects'. But it’s hard 
for me to imagine anything I would do 
in ejbActivate() that I wouldn't 

rather do in some other 
method. 


But after that, I still need 
to ask, u Who am I supposed 
to be?" and thafs when I get the 
Being John Malcom” script with all of my 
characters important data. The Container 
calls my ejbLoad() method to tell me that 
I have everything I need to play the 
0\ role of John Malcom. After that, I'm 
^ \ in character and ready for action. 



o 
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Show time! The client’s business 
method call is finally passed to me. 
(Hey, will somebody tell my psycho 
bodyguard to relax... it’s not easy 
being brilliant, you know...). 



So I say, ''Don’t get your 
knickers in a twist... here's the 
data" (they all act like it’s, literally, 
the end of the world over here if the 
database doesn’t know every little 
thing that happens to my 
character). 


After my stunning performance as 
John Malcom, the Container (who 
takes this job way too seriously) 
calls my ejbStore() method to see if I’ve 
changed any of Johns internal state values. 
Well of COURSE I have—this character, 
through much tragedy, suffering, and 
business logic has grown... as an entity. 

Of COURSE he's a different person. 





O 

o 


❼ 




Then ifs over, and 
I’m back to the pool. 

But first, the Container calls 
my ejbPassivate() method to tell me 
that I’m done being John Malcom, 
and that ifs safe to release any 
resources I was keeping on his 
behalf. I almost never use this 
method, because ifs not an 

efficient way to manage 
things. 
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Activation/passivation of a CMP entity bean 



client 


EJB 



\ 


object 


business method 


Container 



bean^ 


ejbActivate() 


ejbload() 


business method 


ejbStore() 





The Container always calls ejbLoad() after ejbActivate(). 

The Container always calls ejbStore () before ejbPassivate(). 
The Container can call ejb Store () and ejb Store () at other times. 
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arpen your pencil 

If you’re taking the exam, trust us here, you REALLY need to stop right now 
and do this exercise, before turning the page. Think about everything you’ve 
learned in this chapter about the lifecycle of an entity bean, especially how 
and when it comes out of the pool to become an entity. 

Take your best guess about which aspects of beanness are available during 
each of the four container callbacks for ejbActivate(), ejbPassivate(). 



Use your EntityContext to: 


:tivate() 

ejbPassivate() 

ejbLoad() 

ejbStore() 


□ 

□ 

□ 

□ 

get a reference to your home 

□ 

□ 

□ 

□ 

get security information about the client 

□ 

□ 

□ 

□ 

force the transaction to rollback 

□ 

□ 

□ 

□ 

find out if the transaction has already been set to rollback 

□ 

□ 

□ 

□ 

get a reference to your EJB object 

□ 

□ 

□ 

□ 

get your primary key 


Access: 


ejbActivate() 

ejbPassivate() 

ejbLoad() 

ejbStore() 


□ 

□ 

□ 

□ 

methods of another bean 

□ 

□ 

□ 

□ 

your special JNDI context 

□ 

□ 

□ 

□ 

a resource manager (like a database) 
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things you can do during activation a^d loading 



timeline 



ejbActivate() 

Use your EntityContext to: 

□ get a reference to your home 
Ci’get a reference to your EJB object 
\Sf get your primary key 

□ get security information about the client 

□ force a transaction to rollback (CMT 
beans) 

□ find out if the transaction has already 
been set to rollback (CMT beans) 

□ get a transaction reference, and call 
methods on it (BMT beans only, so 
entities can’t use this) 

Access: 

your special JNDI environment 

□ another bean’s methods 

□ a resource manager (like a database) 

(y^O, 

TV\c Co^*ta' mCV Attcss d tcav' 


ISH ： 

s V c6\a\ tascs 一於 


v*csovav*6C 


'Z 




ejbLoad() 

Use your EntityContext to: 

□ get a reference to your home 

Q get a reference to your EJB object 

E get your primary key 

M get security information about the client 

□ force a transaction to rollback (CMT 
beans) 

m find out if the transaction has already 
been set to rollback (CMT beans) 

□ get a transaction reference, and call 
methods on it (BMT beans only, so 
entities can’t use this) 

Access: 

喊 your special JNDI environment 

喊 another bean’s methods 

a resource manager (like a database) 


Wow WC do /,, 

do i h . L. . '* ihi^as 

^ of i his 3s ^ 

^eihod. C9，hh，h 9 ihc 
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things you cam do during passivation amd storing 


timeline 



ejbPassivate() 

Use your EntityContext to: 

□ get a reference to your home 

Cf’get a reference to your EJB object 

贫 get your primary key 

□ get security information about the client 

□ force a transaction to rollback (CMT 
beans) 

□ find out if the transaction has already 
been set to rollback (CMT beans) 

□ get a transaction reference, and call 
methods on it (BMT beans only, so 
entities can’t use this) 

Access: 

if your special JNDI environment 

□ another bean’s methods 

□ a resource manager (like a database) 


By 七 he "time 七 lie Coyrta’mev* stav*"ts "to 
passivate you, youVc y\o lo^gcv- asso^iaied 

Nw'rtii a 乙 lieivt ov* a *bra 灼 sad 七 i 。 灼 
上 st 衫 •七 w 4 i Cca—W 

°^ hc • L) so >y 0 VA 6a^t 

a*t t ^ ^ 代 soVAr tc T 

代 a do 

Co 山心 f a 1 S ' Jf 1 tv*avxsat*t»orx 


TV 




Use your EntityContext to: 

□ get a reference to your home 

^ get a reference to your EJB object 

E get your primary key 

M get security information about the client 

fif force a transaction to rollback (CMT 
beans) 

Hf find out if the transaction has already 
been set to rollback (CMT beans) 

□ get a transaction reference, and call 
methods on it (BMT beans only, so 
entities can’t use this) 

Access: 

喊 your special JNDI environment 

喊 another bean’s methods 

8^ a resource manager (like a database) 


p// ~ this is ExACTL/ -the 

a v hc r cvious oh 此 咖 

2 fir 9 * (oY -the y^oics 

r.+W ' ""XL ^ Wh f S M 。 刪 I d ， 

^ ^ lcs f ov， w idchtidal io 

the <rulcs s-fcoHhg. 
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Commit options: what REALLY happens 
to a bean after a transaction commits? 

( 七 he previous pidtuv-cs art just ONE v/ay ii dould 
wovk, bu 七七 heve av-c *tv/o 。七 hev v/ays) 


① Commit option A 

The bean stays ready, attached to the EJB object, loaded 
with data but NOT in a transaction. The Container keeps the 
entity locked, so that nobody can change the bean’s state. 
When a client calls a business method on this entity bean’s 
EJB object, the Container does NOT do an ejbActivate() or 
ejbLoad(), and assumes the bean’s data is still in sync with 
the underlying persistent store. 


A 



Bean stays connected and in sync. 
When the next business method call 
comes in to the bean, it just runs. No 
ejbActivateQ, no ejbLoadQ. 


Darko 


Donny 


2 咏姆一 A 


② Commit option B 

The bean stays attached to the EJB object, loaded with 
data but the bean’s state is marked as ‘invalid’. In other 
words, the Container knows that the bean might become 
stale between now and the next time a client invokes 
a method on this bean, so the Container will do an 
ejbLoad() when a new business method comes in for this 
entity. (But no ejbActivate()). 


B 



Bean stays connected, but not in sync. 
When the next business method call 
comes in to the bean, ejbload() is 
called. (But no ejbActivate。) 


i ㈣ 广工 。。' 


Darko Donny 42 


⑤ Commit option C 

The bean is passivated and put back into the pool. The 
next time a client calls a business method on this entity, 
everything we’ve seen in this chapter happens—a bean 
comes out of the pool, is activated, the loaded, and 
finally the business method it passed to the bean. 
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C 

Bean is disconnected from the EJB 
object, and goes back to the pool. With 
the next business method call to this 
bean, the Container pulls a bean out of 
the pool, then calls ejbActivate() and 
ejbLoadQ 


4 

# 


Darko 


Donny 
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How does these commit 
options affect me? Do I need to 
know which one my Container is 
choosing? Do I get a choice? 

According to the specification, 
your vendor is free to use any of the 
three options. Your container might let 
you choose (or tune) the option, but 
don’t always count on it. But do you 
need to know which is being used? 

You can see where the trade-offs are, 
of course —— if you keep the entity 
locked in the database, no other 
applications can use that entity’s 
data.That’s fine if the EJB is the only 
application that needs that database. 
And that option (commit option 
A) gives you the best performance 
when a business method call comes 
in for the entity, because there’s 
no ejbActivateO (the bean never 
went back to the pool), and more 
significantly — there’s no trip to the 
database or an ejbLoadO! 

But couldn’t option A really 
kill me, if ■ want to keep the entities 
unlocked in the database when 
they’re not being used by the bean? 

For this reason, most vendors 
won’t use option A as a default; 
they allow it only if the deployer or 
admin chooses it (assuming it’s even 
supported at all). 

I see another, possibly even 
WORSE problem with option A." 
doesn’t this mean a continually 
growing heap full of objects? Like, 
each time someone uses a particular 
entity, an entity bean instance is 


tWeiqre^P 

Dumb Questions 

created that then stays stuck to 
the EJB object? Aren’t pools more 
efficient because you need only 
enough beans to service the actual 
in-progress methods? 

No container worth 
configuring would leave you stuck 
with a constantly, endlessly growing 
accumulation of objects. Even a 
container that does use option A 
can use something like a LRU (Least 
Recently Used) algorithm to say to 
itself,"Hmmm... nobody has called a 
method on entity #908 for a long time, 
so I’ll passivate that bean and put him 
back in the pool (and unlock the row).” 
But, with at least the option of using 
option A, a container can say to itself, 
"This entity #405 is really popular. 

It’s a big pain to keep going to the 
database and doing the whole load/ 
store/activate/passivate cycle each 
time, so I’ll just keep him loaded and 
ready, even between transactions.” 

Oh man, I just thought of 
something REALLY bad with this 
architecture...even if you do NOT 
keep accumulating entity beans, 
what about the EJB objects??? Don't 
they just keep growing and growing 
so that each time a client does a find, 
and gets back a stub, an EJB object 
is created for that entity, and it just 
stays around until the entity itself 
is removed? At any given time, I will 
have all the EJB objects on the heap 
that represent every entity anyone 
has ever accessed up to that point... 

Ah... now we come to the 
difference between the "conceptual” 
view of the architecture, and the 
"actual” implementation. 

According to the spec, you’re 


supposed to assume that this is 
indeed how it works: when a client 
wants an entity bean, either through 
a create or find, the Container makes 
an EJB object for that entity ("here’s 
the EJB object for #24, here's the 
EJB object for #98'; etc.). And as a 
Bean Provider (as opposed to, say, a 
container/server provider), you are to 
program as if that’s really the way it 
works. 

But internally, the Container might 
be doing something quite different 
from the conceptual architectural 
view. Imagine that YOU were a 
container developer — how would you 
implement things? 

One idea might be to put the burden 
on the clients, by keeping all the 
information in the stubs. For example, 
when the client gets a stub to an 
EJB object,you can make sure that 
the stub knows the unique ID for 
the entity (i.e.the primary key). But 
the EJB object’s might be generic, 
in such a way that when the client 
calls a method on a stub, that stub is 
connected not to an EJB object just 
for that entity, but rather a one-EJB 
object-fits-all that knows how to make 
sure the method ends up at the right 
entity. That way, when a client isn’t 
using an EJB object,that EJB object 
isn’t sitting around wasting space. 
That’s just one idea. 

That might be fine for stubs, 
but what if the client is local? Then 
they have a real reference to the 
EJB object, so that EJB object would 
HAVE to be entity-specific. 

Yes, that's true. But with 
local clients, normal Java garbage 
collection works. When there are no 
clients with references to a particular 
EJB object, the instance will die. 
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Which of the three commit 
options do you think is most used? 

Well... we can't really answer 
that, but if we were in a betting mood, 
our money would be on option B. A 
'smart'option B,that knows when it 
makes sense to hang on to a bean 
and when it doesn’t. But avoiding the 
ejbActivateO, which is usually useless 
anyway, is a Good Thing. 

But isn’t the hit to the 
database — the load — a much bigger 
hit than just one more method call 
on the stack? 

First of all, activation is 
probably a little more than just 
one more method call on the stack, 
because there’s overhead just in 
maintaining the organization of the 
pool itself. But yes, you’re right about 
the database hit being a bigger deal. 
But... there’s all sorts of ways the 
Container can optimize, and what’s 
the alternative? The only alternative 
(option A) keeps the database locked, 
which is typically not what you want. 

But what if my EJB app IS the 
only thing that uses that database? 

I think we mentioned this 
earlier...if you know absolutely 
positively no question that your EJB 
app is the only thing touching that 
database, then yes, if your vendor 
supports it,you’ll have better 
performance with option A. Of course, 
caching things in memory is 


tWeiqre^P ^ 

Dumb Questions 

still dangerous, because entities are 
persistent! So the vendor still must 
implement something that saves the 
state of the entities to the database, 
if they change. So there will still be 
storing, if not loading. 

There are still other potential prob¬ 
lems with option A, though. For 
example, you might have a server 
that supports clustering, and the 
server will have to be certain that all 
instances of that entity bean in sync, 
not just with the database, but with 
one another. But that’s another issue. 
You’ll learn more in the patterns and 
performance chapter. 


So is the real point of all this 
the fact that as long as you’re in a 
transaction, you won’t have all these 
load/store activate/passivate calls? 

Yes, a big port of the point, 
anyway. 


Then shouldn’t your goal be 
to have the longest transactions? 

You aren’t being serious, right? 
Just for fun, we’ll pretend you are, and 
say, NO NO NO NO.Think about your 
concurrency. A good rule of thumb 
(with a zillion exceptions, of course so 
all rule-of-thumb disclaimers apply) is 
that transactions should be no longer 
than absolutely necessary. The longer 
your bean is in a transaction, the more 
likely it is that others are waiting in 
line to get to that entity! Of course, 

it’s also possible to have transactions 
which are too s/iorf, which means 


you’re doing more loads/stores than 
you need to, so the key is to have your 
transactions be as long as you need, 
and no longer. 


One more thing... doesn’t 
this mean that ejbPassivate and 
ejbActivate might not ever be called 
on a bean, if the container uses 
option A or B? And doesn’t this mean 
that I shouldn’t rely on ejbActivate 
or ejbPassivate in my design? 

A: YES! That's EXACTLY what it 
means. It’s usually a lousy strategy. But 
you can imagine how it might sound 
like a good idea... 
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EmctS^ 


CMP entity bean Creation 


Fill in the five missing arrow labels for the object interaction 
diagram. Remember, they aren’t necessarily method calls. This 
is exactly the same diagram that you saw earlier in the chapter. 
Except yours will look nicer, because you’ll probably make it all 
fancy with exotic symbols and maybe color-coded markers and... 


client 


create() 
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Entity Bean Business Method 
(with activation & passivation) 

This time, you’re gonna draw the arrows yourself! Assume that the bean is in the pool at the 
time the client calls a business method (which also means the bean is not in a transaction). 
Draw arrows and label them with the actions that occur through the completion of the 
business method. Show what happens when the bean returns to the pool. 

When we did it, there were eight more arrows, but you might have more or less depending 
on how you want to do it. Do NOT flip back through the most recent pages. You can do this. 
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Fill in the ProductBean UML-ish box with the methods that YOU must write 
in your bean class, given the component and home interfaces. Don’t forget 
the container callbacks from EntityBean, although we’ve shown you only 
three of the seven. The rest you’ll have to remember and fill in. 


ProductBean 


〈〈 interface 〉〉 

Entity Bean 




ejbActivatef) 


ejbRemove() 

unsetEntityContext() 







〈〈 interface 〉〉 

ProductHome 

create (String ID, String price, String description) 
findByPrimaryKeyfString key) 
getLowInventoryfint limit) 


«interface» 

Product 


L 


getProductDescription() 

getQuantity() 

getPricef) 
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"TKcck Sxom 


What’s true for a bean provider when creating an entity bean using container- 

managed persistence? (Choose all that apply.) 

[I A. Container-managed persistent fields must be defined in the entity bean 
class. 

Q B. Container-managed relationship fields must be defined in the entity 
bean class. 

口 C. When implementing a one-to-many relationship, the java.util.List 
interface must not be used. 

口 D. Accessor methods for container-managed relationship fields must be 
exposed in the bean’s remote component interface. 


Which of the following is a legal accessor method for a persistent field in an 
entity bean with container-managed persistence? (Choose all that apply.) 

□ A. public getCustomerNum(); 

□ B. public void getCustomerNum(); 

Q C. abstract void getCustomerNum(); 

□ D. public abstract int getCustomerNum(); 


3 


Which of the following are legal accessor method (s) in an entity bean with 
container-managed persistence? (Choose all that apply.) 

□ A. public abstract int GetCustomerNum(); 

□ B. public abstract int getcustomerNum(); 

□ C. public abstract int getCustomerNum(); 

□ D. public abstract int getCustomerNum() { }; 
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4 


5 


Which are requirements for a CMP entity bean class? (Choose all that apply.) 
Q A. The class must define a finalize () method. 

Q B. The source file must define at least one constructor. 

[I C. The class must be declared public and abstract. 

口 D. The class must implement, directly or indirectly, the 

javax. ejb. EnterpriseBean interface. 

口 E. All getter and setter methods for the bean’s abstract persistence 
schema must be abstract. 

Which are legal declarations for a CMP bean’s ejbCreate methods? (Choose 
all that apply.) 

□ A. public void ejbCreateBigCustomer () throws 

javax•ejb.CreateException 

□ B. public String ejbCreateAccount() throws 

javax.ejb.CreateException 

□ C. static String ejbCreate() throws 

javax.ejb.CreateException 

□ D. public int ejbCreate() throws 

javax.ejb.CreateException 

□ E. public final String ejbCreate () throws 

javax.ejb.CreateException 


6 


Which are legal declarations for a method in a CMP bean? (Choose all that 
apply.) 

□A. public Account ejbSelectAcct(long x) throws 
javax.ejb.FinderException 

□ B. public abstract Acct ejbSelectAcct(long x) throws 

javax.ejb.FinderException 

□ C. public Account ejbPostCreate(Acct key) throws 

javax.ejb.CreateException 

□ D. public void ejbPostCreate(Acct key) throws 

javax.ejb.CreateException 

□ E. public static void ejbPostCreate(Acct key) throws 

javax.ejb.CreateException 
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Which method (s) from the EntityContext interface can be invoked from 
within the setEntityContext method? (Choose all that apply.) 

Q A. getEJBObject() 

口 B. getEJBLocalHome() 

□ C. getCallerldentity() 

口 D. getCallerPrincipal() 

□ E. setRollbackOnly() 



Which can be called on a CMP bean to transition it from the ready state to the 
pooled state? (Choose all that apply.) 

□ A. ejbStore () 

□ B. ejbCreate () 

□ C. ejbSelect () 

□ D. ejbRemove () 

□ E. ejbPassivate() 


Which method (s) from the EntityContext interface can be invoked from 
within the ejbCreate method? (Choose all that apply.) 

□ A. getEJBHome () 

□ B. getEJBObject() 

□ C. getCallerPrincipal() 

□ D. getUserTransaction() 

□ E. setRollbackOnly( ) 


10 


What is true for a CMP bean in the ready state? 

Q A. Its e jbLoad () can be called directly after ejbStore. 

Q B. Its ejbStore () can be called directly after a business method. 
口 C. One of its business methods can be called directly after ejbStore. 
Q D. None of the above. 
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Which method (s) from the EntityContext interface must NOT be invoked 
from within the ejbLoad method? (Choose all that apply.) 

□ A. getEJBHome () 

□ B. getEJBObject() 

□ C. getCallerPrincipal() 

□ D. getUserTransaction() 

□ E. setRollbackOnly () 

Which method, called on a CMP bean, is ALWAYS associated with a state 
change in the bean? (Choose all that apply.) 

□ A. ejbLoad () 

□ B. ejbFind() 

□ C. ejbRemove () 

□ D. ejbActivate () 

□ E. unsetEntityContext () 

What’s true about an CMP entity bean’s primary key? (Choose all that apply.) 

Q A. The bean’s primary key class must provide a suitable implementation of 
the hashCode and equals methods. 

口 B. When specifying the primary key in the deployment descriptor, only 
the field name must be declared 

口 C. All fields in the primary key class must be declared public. 

口 D. All fields used in the primary key must be container-managed fields. 


How many ejbCreate methods can a CMP entity bean have? 


□ 

A. 

0 



□ 

B. 

1 



□ 

C. 

0 

or 

1 

□ 

D. 

0 

to 

many 

□ 

E. 

1 

to 

many 
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Which method (s) are always invoked in direct response to a client operation? 
(Choose all that apply.) 

□ A. ejbLoad () 

□ B. ejbCreate () 

□ C. ejbRemove () 

□ D. ejbActivate () 

□ E. ejbPassivate() 

□ F. setEntityContext () 


16 


Which additional method (s) might the container call when invoking 
ejbRemove? (Choose all that apply.) 

□ A. ejbFind() 

□ B. ejbLoad() 

□ C. ejbStore () 

□ D. ejbActivate () 

□ E. ejbPassivate() 


17 


At what point(s) must the container establish a CMP bean’s primary key? 
(Choose all that apply.) 


□ A. before calling newlnstance () 

□ B. before calling setEntityContext () 

□ C. before calling ejbCreate () 

□ D. before calling e jbPostCreate () 


Which method (s) run in the transaction context of the method that causes 
their invocation? (Choose all that apply.) 

□ A. ejbLoad () 

□ B. ejbRemove () 

□ C. ejbSelect () 

□ D. ejbActivate () 

□ E. ejbPassivate() 

□ F. setEntityContext () 
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CCk 繫尹它它 

IHock Sxom /ia^e^ 



What’s true for a bean provider when creating an entity bean using container- 
managed persistence? (Choose all that apply.) 


Q A. Container-managed persistent fields must be defined in the entity bean 
class. 


□ B. 
^ C. 


Container-managed relationship fields must be defined in the entity 
bean class. 

When implementing a one-to-many relationship, the java.util.List 
interface must not be used. 




ciC 


口 D. Accessor methods for container-managed relationship fields must be 
exposed in the bean’s remote component interface. 


Which of the following is a legal accessor method for a persistent field in an 
entity bean with container-managed persistence? (Choose all that apply.) 


□ 

□ 

□ 

d 


A. public getCustomerNum(); 

B. public void getCustomerNum(); 

C. abstract void getCustomerNum(); 

D. public abstract int getCustomerNum(); 




Which of the following are legal accessor method (s) in an entity bean with 
container-managed persistence? (Choose all that apply.) 


□A. public 

□ B. public 
^ C. public 

□ D. public 


abstract 

abstract 

abstract 

abstract 


int GetCustomerNum(); 
int getcustomerNum(); 
int getCustomerNum(); 
int getCustomerNum() { 


- you have -to -follov/ 七 he 
Java doir>vc^-t*ioir> 
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4 


5 


Which are requirements for a CMP entity bean class? (Choose all that apply.) (sW. I ⑽） 

Q A. The class must define a finalize () method. 

口 B. The source file must define at least one constructor. - Uo, you "the dc-fau!*t do^s*bvu6*to\r 
^ C. The class must be declared public and abstract. 

^ D. The class must implement, directly or indirectly, the 

javax • ejb. EnterpriseBean interface. 

^ E. All getter and setter methods for the bean’s abstract persistence 
schema must be abstract. 


Which are legal declarations for a CMP bean’s ejbCreate methods? (Choose 
all that apply.) 


(s? 私 : I 私 ) 


□ A. public void ejbCreateBigCustomer() throws 

javax.ejb.CreateException 

^ B. public String ejbCreateAccount() throws 
javax.ejb.CreateException 

Q C. static String ejbCreate() throws 
javax.ejb.CreateException 

□ D. public int ejbCreate() throws 

javax.ejb.CreateException 


\i 63^ *k W 

- mo\A 

# ? 一 a ” 


□ E. public final String ejbCreate () 
javax.ejb.CreateException 


6 


Which are legal declarations for a method in a CMP bean? (Choose all that 
apply.) 


(s ? e6 ： 1U -⑼) 


A. public Account ejbSelectAcct(long x) throws 
javax•ejb.FinderException 

B. public abstract Acct ejbSelectAcct(long x) throws 
javax•ejb.FinderException 

C. public Account ejbPostCreate(Acct key) throws 
javax.ejb.CreateException 

^ D. public void ejbPostCreate(Acct key) throws 
javax.ejb.CreateException 

□ E. public static void ejbPostCreate(Acct key) throws 
javax.ejb.CreateException 


□ 

□ 




mo\A 


一 6a^*t 
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Which method (s) from the EntityContext interface can be invoked from 
within the setEntityContext method? (Choose all that apply.) 


_ m) 


□A. getEJBObject() 

B. getEJBLocalHome () 

Q C. getCallerldentity() 
口 D. getCallerPrincipal() 
□ E. setRollbackOnly() 




— O W L^Oif I I —•■I w - 

called bo "bra ⑽ rtion -the bca^ 


Which can be called on a CMP bean to transition it from the ready state to the 
pooled state? (Choose all that apply.) 

Q A. ejbStore () 一 s*tovc be ddllcd a 灼 d is v\oh 

□ B. ejbCreate () 

□ C. ejbSelect() 

^ D. ejbRemove () 一 y/i*th cjbRcmovcO, -the bca^ y/or\ *t jet Bv\ 

^ c\kPass*iva-tcO 

Q E. ejbPassivate () 


(s ? e6 ： ㈣ 潤 ) 


Which method (s) from the EntityContext interface can be invoked from 
within the ejbCreate method? (Choose all that apply.) 

^ A. getEJBHome () 

^ B. getEJBObject( ) 

0 r C. getCallerPrincipal () K/f'/tR 

□ D. getUserTransaction () - ^ i cr't't'/ 

^ \y\VoKC *tn > CtAT 

2T E. setRollbackOnly () wvas*c 


What is true for a CMP bean in the ready state? 

A. Its e jbLoad () can be called directly after ejbStore. 

B. Its ejbStore () can be called directly after a business method. 
^ C. One of its business methods can be called directly after ejbStore. 
Q D. None of the above. 


_ m) 


㈣ 潤 ) 


一丁 k ?o^*k » s： 

load, sWe If 

ordev 


you are here ► 369 






mock exam answers 


Which method(s) from the EntityContext interface must NOT be invoked I ®。） 

from within the ejbLoad method? (Choose all that apply.) 

□ A. getEJBHome () 

□ B. getEJBObject() 

Q C. getCallerPrincipal() 

^ D. getUserTransaction ( ) - 好則丁 
Q E. setRollbackOnly () 

- (s_ : IW 肩 ) 

Which method, called on a CMP bean, is ALWAYS associated with a state 
change in the bean? (Choose all that apply.) 

Q A. e jbLoad () 一竹 0 七 a!ways| 

□ B. ejbFind() » 

aT c. e jbRemove () - ^ oCS 

D. e jbActivate () - bca 扒 domes ou*b o-P fool 

^ E. unsetEntityContext() - bcah goes -fvom -the pool io dcaih 

What’s true about an CMP entity bean’s primary key? (Choose all that apply.) 

^ A. The bean’s primary key class must provide a suitable implementation of 
the hashCode and equals methods. 

口 B. When specifying the primary key in the deployment descriptor, only 
the field name must be declared - y\o, you v\ttd "the "tyfc 

^ C. All fields in the primary key class must be declared public. 

D. All fields used in the primary key must be container-managed fields. 

How many ejbCreate methods can a CMP entity bean have? 


( s _: 谈,讲 


(s? 私 : 


111 ) 


□ A. 0 

□ B. 1 

□ C. 0 or 1 
^ D. 0 to many 
Q E. 1 to many 
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Which method(s) are always invoked in direct response to a client operation? 
(Choose all that apply.) 

Load, Passwatc, 


: ni 」 n) 


□ A. ejbLoad () 

B. ejbCreate () 

^ C. ejbRemove () 

□ D. ejbActivate () 

□ E. ejbPassivate() 

□ F. setEntityContext () 




Yid 


yxts *ko 


Which additional method(s) might the container call when invoking 
ejbRemove? (Choose all that apply.) 


t ^： nw 


□ A. ejbFind() 

5^ B. ejbLoad () 

□ C. ejbStore () 

D. ejbActivate() 

□ E. e jbPassivate () 


a kca^ has -to be ready 
ay\d loaded bc-Po\rc i*t 
tav\ do a remove - i-t 

a have 

-to -take dav-c 




鱗織 ㈣ 


At what point(s) must the container establish a CMP bean’s primary 
(Choose all that apply.) 

□ A. before calling newlnstance ( ) 

□ B. before calling setEntityContext () 

Q C. before calling ejbCreate () 

^ D. before calling e jbPostCreate () ^ 

Which method (s) run in the transaction context of the method that causes (s^c6 : 门今-门幻 
their invocation? (Choose all that apply.) 

^ A. ejbLoad () 

B. ejbRemove () 

C. ejbSelect () 

□ D. ejbActivate () 

□ E. e jbPassivate () 

□ F. setEntityContext () 
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w 


When Beans Relatt 



Oh really? Too bad you don’t 
have a Container to manage your 
referential integrity. Because 
I would just love to cascade- 
delete you right now... 〆 


,Have you heard 
about One-to-Many 
relationships? I thought 
T maybe we could try 
that... / 




Entity beans need relationships. An Order needs a Customer. A Lineltem 
needs an Order. An Order needs Lineltems. A Movie needs a Director. A Director needs 
Movies. A Movie needs Actors. An Actor needs talent... Entity beans can have container- 
managed relationships (CMR) and the Container takes care of virtually everything. Make 
a new Movie and give it a Director? That Director automatically has one more Movie in his 
Movie collection. Make a new Lineltem that’s related to an Order? If you ask the Customer 
to show you his Orders, his Orders will show the new Lineltem. Best of all, you can use 
EJB-QL to write portable (think: vendor/databse independent) queries. 


this is a new chapter 
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Ct neoiijcf meaa^: 


6.2 Identify correct and incorrect 
statements or examples about 
persistent relationships, remove 
protocols, and about the abstract 
schema type, of a CMP entity bean. 

6.3 Identify correct and incorrect 
statements or examples about 
rules and semantics for relationship 
assignment updating, in a CMP bean. 

6.4 Match the name with a description of 
purpose or functionality for each of 
the following: <ejb-name>, 〈 abstract- 
schema-name>, <ejb-relationship-role>, 
<cmr-field>, <cmr-field-type>, and 
<relationship-role-source> 

6.5 Identify correctly implemented 
deployment descriptor elements for 
a CMP bean (including container- 
managed relationships). 

9.1 Identify correct and incorrect syntax 
for an EJB-QL query including the 
SELECT, FROM, and WHERE clause. 

9.2 Identify correct and incorrect 
statements or examples about the 
purpose and use of EJB-QL. 

9.3 Identify correct and incorrect 
conditional expressions, between 
expressions, like expressions, and 
comparison expressions. 
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You have to know that the container manages 
relationships between two entity beans through 
container-managed persistent (CMR) fields, and that 
CMR fields must be described in the deployment 
descriptor using the 〈 relationships 〉 section. 

You have to understand the implications of multiplicity 
in a relationship, and that the Container cares whether 
the relationship is one-to-one, one-to-many, or many- 
to-many. You must know that the Container maintains 
the referential integrity of the database by using the 
multiplicity when doing assignments. For example, if 
there can be only one Customer per Order, if you assign 
an Order to a Customer, that Order cannot exist in any 
other Customer’s Order collection. And if you reassign 
that Order to a different Customer, the Order is moved 
from one Customer’s collection to the other. But if you 
assign a Customer with three existing Orders, to another 
Order, the reference to the Customer is copied, not 
moved, so that the reference to a Customer that the 
other three existing Orders have, is not affected. 

You have to know that EJB-QL queries are defined in 
the deployment descriptor, and are for Finder and Select 
methods only. You have to know the basic syntax of EJB- 
QL, and that FROM and SELECT are mandatory, but 
WHERE is optional. 

You have to know that if you use path navigation to, say, 
get the title of a Movie, you can say m.title (assuming “m” 
is declared as the abstract schema type of Movie, and 
"title” is a CMP field of the MovieBean). But that you can’t 
say d.movies.title where “d” is a Director, and “movies” is 
a CMR field that is a Collection of movies. For that, you 
must use the IN operator within a FROM clause. You’ll 
see... it’s all in here. And much simpler than it sounds. 
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Peanifying your movie database 

Imagine you have a movie application (it isn’t making the 
folks at imdb.com nervous, but it works for you). 

You can use it to look up a movie. 

Once you have a movie, you can use it to launch the movie 
trailer. 

You can do all kinds of searches to, say, find all sci-fi movies, 
or find all action movies by a specific director. 

We can make beans for Movie, Trailer, and Director. But 
how do they map to the database? And how do they relate 
to one another? r 


Movie Table 




MovielD 

Title 

Genre 

DirectorlD 

Year 

12 

Crouching Pixels, Hidden Mouse 

Action 

42 

2000 

5 

The Fifth Array Element 

Action 

27 

2003 

22 

The Return of the Bean Queen 

Fantasy 

27 

2001 

11 

Lord of the Loops 

Sci-fi 

42 

2002 



Director Table 


Trailer Table 


DirectorlD 

OscarWinner 

Degrees 

Name 

27 

TRUE 

3 

Jim Yingst 

42 

FALSE 

6 

Jessica Sant 

56 

FALSE 

24 

Skyler Safford 

17 

FALSE 

5 

John Dawson 


TrailerlD 

FileName 

12 

Crouching Pixels, Hidden Mouse Trailer 

5 

The Fifth Array Element Trailer 

22 

The Return of the Bean Queen Trailer 

11 

Lord of the Loops Trailer 


P'lVCt*boV doesn't have a 

於 tc "to Wis movies. 
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Putwc dow't wawt to think \v\ TAPIES 
Wc wawt to think in CLASSES 


We know we can map tables to bean classes, no problem. 
All the columns become persistent fields in the bean class, 
represented by abstract getters and setters, and we’re 
good to go. Except... if this were a class and not a table, we 
wouldn’t have designed it that way. We’d probably make 
the movie class a lot more friendly and useful, for example, 
so that a client could work with just the movie bean, rather 
than having to get references to all three beans. 


L ? 

: 如 ㈣㈣ t 


MovielD 

Title 

Genre 

DirectorlD 

Year 

12 

Crouching Pixels, Hidden Mouse 

Action 

42 

2000 

5 

The Fifth Array Element 

Action 

27 

2003 

22 

The Return of the Bean Queen 

Fantasy 

27 

2001 

11 

Lord of the Loops 

Sci-fi 

42 

2002 



DirectorlD 

OscarWinner 

Degrees 

Name 

27 

TRUE 

3 

Jim Yingst 

42 

FALSE 

6 

Jessica Sant 

56 

FALSE 

24 

Skyler Safford 

17 

FALSE 

5 

John Dawson 


TrailerlD 

FileName 

12 

Crouching Pixels, Hidden Mouse Trailer 

5 

The Fifth Array Element Trailer 

22 

The Return of the Bean Queen Trailer 

11 

Lord of the Loops Trailer 


Movie 


getTrailerlD() 

getFileName() 


getMovielD() 

AetTitle() 

etGenre() 

etDirectorlD() 

etYear() 



3 s-tvaijli*t -fvom 

tables -to classes 




getDirectorlD() 

getOscarWinner() 

getDegrees() 

getName() 
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Wouldn’t it be dreamy if there 
were a way to use container-managed 
persistence, but have classes that didn't 
have to look exactly like the tables? So that 
a client could get a movie, and ask the movie 
for a real Director reference, not just the 
directors foreign key... yeah, that would 
be great, but it’s probably just a 
fantasy... 
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Wc need relationships between the Movie bean 
and the Pircctor bean 

We want the Movie bean to have a reference to its matching Director bean and 
we want to do all sorts of searches against the Movie bean and have the queries 
use the Director bean’s data as well. 

In other words, we want to make it easy on the client (and on the developer) to 
think in a more natural way, rather than in the database-efficient way that was 
used to design the schema of the database. Who wants that? Remember, this is 
the OO world and relational databases, while crucial to your business, are so 
1999. We want to use databases, we just don’t want to think like databases. (If 
you’re one of the lucky ones who gets to use an OO database, and assuming 
that database still somehow manages to perform well enough for your needs, 
then you can just smile smugly during this first section.) 


instead of this 


we want this 



We’re not going to use the Trailer table and bean after this (although you’ll 
see it in code), to keep the example cleaner. Adding the Trailer bean wouldn’t 
add any new complexity to the application, though. If you can set-up one 
bean-to-bean relationship, you can set up others. 
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Why should the Pircctor be a bean? 
Why caw't it just be data? 


Why not have the Movie bean simply go to the database, 
using the Director’s foreign key (stored as a persistent 
field in the Movie bean), and get the Director’s data? But 
if you make the director a bean as well, you get to think 
ONLY in objects (except during deployment, when you 
do have to map from your beans to your tables). And you 
get all the benefits of container-managed persistence and 
synchronization. Imagine if someone calls a setter method 
to change the director’s oscar winning status. If you’re 
managing this, you’d have to get a JDBC connection and 
synchronize the database yourself. And of course, you’d have 
to know when is the right time, etc. But if its director is also a 
bean, you call a setWinner() method, and you’re done. 

Oh, and there’s another cool thing. You might decide, for 
example, to banish a specific director from your database, 
because you think his movies suck in an unrecoverable way. 
No problem deleting that director, obviously. But then what 
happens to the movies? How can you have movies in the 
database that don’t have a director? What is the database is 
already set up in such a way that you aren’t allowed to have a 
null value for the director column? In other words, what if a 
movie cannot exist in the database without a director? 

You can handle this brainlessly, by setting up the Movie- 
to-Director bean relationship in such a way that when you 
delete a director from the database, all of his movies are 
automatically deleted! You do this with one simple tag in the 
deployment descriptor and POOF! Somebody calls remove () 
on a director bean, and remove () will automatically be called 
on all of the movie entity beans that have a reference to this 
director (as the value of their director persistent field). 


If bofliilie Director and 
ike Movie are entity beans, 
you never Have to worry 
about syncltfonizing any 
of the Movie's related 
data； if somebody uses 
ike Movie bean to cKange 
someftog about ike Director, 
everyfliing's taken care of by 
the Container. 

You can even set teigsup 
for a cascade - delete … so if 
you remove a Director, all 
lire Director's movies will be 
removed automatically! 
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Relationships and multiplicity 




Each Movie 
One Movie 


has 

has 


_ One Trailer 
— Each Trailer 





One Director 


has 


Each Movie 


③ Mawy - fo - Many 



An Actor 
Many Actors 


has made 
has 



Many Movies 
A Movie 
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Multiplicity m Pean Classes 

Here’s how it works with our bean code. This multiplicity notation 
is the only UML-like thing you have to know on the exam. 



To read this, you have to follow the arrow to its destination. In 
the Person to Pets relationship, Person has a multiplicity of ONE, 
but Pets has a multiplicity of MANY (which could be zero). To 
find out how many Pets a Person can have, you have to follow 
the arrow out of Person and into Pets. The number closest to the 
class is the multiplicity of that class to others. In other words, how 
many of that type does the other type have. 



iKis humbcv- says 

Kow r»>air»y PBRSON 

objcdts does eadK 

PBT Kavc 


? l T g dots 

person ^ 



0 ., 


* 
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Multiplicity affects rctorw type! 

A Movie has one Director. When you call getDirector(), you 
get back one Director. So the return type of getDirector() is 
a Director(). 

But a Director has many movies, so when you call 
getMovies(), you get back a Collection of Movies. 


Multiplicity: Multiplicity: 



Movie lids a r»»ul*bipli6-by o( 
W nr»ahy W m i*ts v-da*tiohsliip 

Pivc^*tov. TKa*t does MOT 

Alovic lids U nr»ahy W 
Pivctiovs... i*t nr»catr\s -tiiat 
Pivc£.*tov- \\Bs Movies/ 


£o Pivc^*tov lias a ytMovicsO 
vc*tuv-hs a Collc^*tioh 

Movies. 


In the Movie-to-Director relationship, the multiplicity of 
Movie is many and the multiplicity of Director is one. 


Piv-c^-fcov V»as a mul*tipli^i*ty 

o( medhs 

Alovic y/ill vetuvh jus 七 
Pivcfi.*tov. 


A multiplicity of one means the object you’re related to 
holds just one of you. 


Director has a multiplicity of one, so the Movie object related 
to Director returns just a single Director bean (OK, technically 
the component interface of Director, but you know what we 
mean by now). 

A multiplicity of many means the object you’re related to 
holds a Collection of you. 


Movie has a multiplicity of many, so the Director object 
related to Movie returns a Collection of Movie beans. 
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Pefiwiwg virtual fields for pcrsistcwt 
data fields and relationship fields 


In the previous chapter we looked at defining container-managed 
fields — you put in a pair of abstract getters and setters. We said a 
container-managed field exists simply because you have a getter and setter for 
it. It works the same way with container-managed relationship (CMR) 
fields. You define a pair of abstract getters and setters, but rather than 
setting and returning a value that maps to a column in a table, you set 
and return a reference to another entity bean, or a Collection that will 
hold references to the entity bean. The restrictions for CMR fields are 
that they can refer only to the local component interface of the entity 
bean, and that if the method returns a Collection, the declared type 
can be only Collection or Set (not Map, List, etc.) 

The terminology is a little confusing because both CMP and CMR 
fields are container-managed persistent fields. They might have 
called it CMPCD (container-managed persistent column data) fields 
and CMPR (container-managed persistent relationship) fields. Of 
course, persistence isn’t restricted to just relational database, so we’re 
using the term “column” a little loosely. But in EJB 1.1 ，all container- 
managed persistent fields were CMP fields, because there was no 
concept of persistent relationships in EJB 1.1 CMR 

You need a pair of abstract getters and setters for 
each CMP field (column values) and each CMR field 
(relationship with another entity). 

① CMP field 


The only difference 
between a CMP field and 
a CMR field is ^ie TYPE. 

A CMR field is always 
anodier entity bean’s 
local interface type, or a 
Collection of them. 

If it’s a Collection, 
it must be eito 
java.«til.Collection or 
java.util.Set. 


public abstract String getTitle () ; ^ u 七 

public abstract void setTitle (String g) ; 七 


② CMR (relationship) field 

public abstract Director getDirector () ; ^ . 

public abstract void setDirector (Director d) ; P»v-c6*tov- 

V 丨 rtual aUavs 

\ota\ -tvpc, ov a 


ry if ft* w ， 

-fov *tKc 
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Pefinmg your abstract persistence 
schema" (virtual fields aren't enough) 


To define persistent fields and relationships, you need to 
create an abstract persistence schema. Defining the virtual 
fields isn’t enough. Your abstract persistence schema is a 
combination of your virtual fields in your bean class, plus 
some things you write in the deployment descriptor. 

The way you describe CMP fields in the DD is simple and 
straightforward. With CMR, you’ll have to do a little more 
to set things up, including describing the multiplicity for 
each of the two participants in a relationship. 

But we’ll get to CMR fields in just a minute. For now, we’ll 
start with just CMP fields. 

The Container needs these TWO things to 
know you have a CMP field "title" 


① In the DD 

<entity> 

<ejb-name>MovieBean</ejb-name> 

<local-home>headfirst.MovieHome</local-home> 
<local>headfirst. Movie</local> 


An abstract persistent scKema 
is a combination of some stuff 
you put in the deployment 
descriptor, plus your abstract 
getters and setters. 

Togefiier, 也 ey tell the 
Container howto manage your 
bean’s persistence, including 
bofli persistent FIELDS 
(called CMP fields) and 
persistent RELATIONSHIPS 
(called CMR fields). 


<ejb-class>headfirst.MovieBean</ejb-class> 
<abstract-schema-name>MovieSchema</abstract-schema-name 〉 


<cmp-field 〉 

<fie 1 d-name >ti tl e</fie 1 d - name> 
</cmp-field> 

• • • 

<entity> 

© In the bean class 

public abstract String getTitle(); 

public abstract void setTitle(String g); 
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Persistent CMP fields in the 99 


/ 


<entity> 

<display-name>MovieBean</display-name> 

<ejb-name>MovieBean</ejb-name> 

<local-home>headfirst.MovieHome</local-home> 
<local>headfirst. Movie</local> 

<ejb-class>headfirst.MovieBean</ejb-class> 
<persistence-type>Container</persistence-type> 
<prim-key-class>java.lang.String</prim-key-class> ^ 
<reentrant>False</reentrant> 

<cmp-version>2.x</cmp-version> 

<abs tract - s chema - name>MovieSchema</abstract-schema - name> 

<cmp-field 〉 

<field-name>genre</field-name> 

</emp-field 〉 

<cmp-field> 

<field-name>movieID</field-name> 

</emp-field 〉 

<cmp-field 〉 

<field-name>year</field-name> 

</cmp-field> 

<cmp-field> 

〈 field—name>title</field-name> 

</emp-field 〉 

<primkey-field>movieID</primkey-field> 


二絲 1 

(as o^ostA ^ 


> -P^lly-quali-ficd dass 
\o>r ihc field 
that v-cpircsch-b 
p^rirnavy key 





\t 




<entity> 


The naming 
convention is 
REQUIRED! 

You must have a pair of abstract 
getters and setters that have the 
first character after the “get” and 
“set” capitalized, but in the CMP 
field definition in the DD, you start 
with a lowercase letter, leaving off 
the “get” and “set”. In other words, 
you define the CMP field in the 
DD as if it were a real instance 
variable, following the old pre-EJB 
JavaBeans naming convention. 


_t]i©reiarejip 

Dumb Questions 


How does the Container know the type 
of the persistent field? I see a definition for the 
primary key type (<prim-key-class>, but I don’t 
see anything for the other CMP fields. 


A ： 


The Container figures it out based on the 
return type and argument of the abstract getters 
and setters in the bean class. And they had better 
match! If you have a getLimitNum() that returns 
an int,you better have a setLimitNum(int i) that 
takes an int. 
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Using relationships m your code 


In your bean code, you use your virtual relationship fields just 
as you would any other getter and setter. The only difference 
between using a real field (i.e. an instance variable declared in 
your class) and a virtual field is that you can access your virtual 
fields only by calling the abstract getters and setters (which the 
Container implements at deploy-time). 

The only new restriction is that a relationship field can be 
only a local component interface type! You can’t have a CMR 
relationship field that uses a bean’s Remote interface! 


Virtual field in the bean class 


public abstract Director getDirector (); 
public abstract void setDirector (Director d); 

TV>e av-<\uw\cy\"t *bY? c ^ 

C 威 Md" *«s aUavs 

Wd 仫如 tr^hiis Remote 

Exposed business method in the bean class 


public Director getMovieDirector() { 

return getDirector (); 




You can use your virtual 
relationsliip fields just 
as you would any adier 
virtual field... by calling 
the abstract fetters tfiat 
YOU defined, but Avliicli 
the Container implements. 

The type of a relationsliip 
field MOST be ^ie local 
component interface of 
the entity! 

A CMR field will 
ALWAYS he a local 
component interface type. 


public String getMovieDirectorName() { 

return getDirector().getDirectorName() 


\ 


iwdrr j _?吟 do 毛 ^ 吹 如 
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defining relationships \v\ your abstract 
persistence schema (in the PI?) 

CMP field definitions are so easy. You declare a <cmp-field> and give 
it a name that matches one of your getter/setter pairs (following the 
naming rule of dropping the “get” and “set” and beginning the CMP 
field name with a lower-case letter). 

But CMR is more involved. You can’t be in a relationship with only 
yourself, so a relationship always includes two beans! 


① Define an ejb-relation between two beans 4 








Define an ejb-relationship-role for one bean 

① multiplicity for this bean <__ ^- s 七 如 11 OTtttR ?art 心 ? wave 

② source for this bean 咖仏 ame 代 alb/ about? 

③ cmr-field for this bean <__ Mus 七 七 k Wd 、 如 1 > ca “ lass 

© cascade-delete for this bean 


Whch ，is P 釙 W is deiced. 


dclcicd 


® Define an ejb-relationship-role for the second bean 


© multiplicity for this bean 
② source for this bean 
© cmr-field for this bean 

@ cascade-delete for this bean 
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relationships in the deployment descriptor 


Relationship definition for the 
Director-to-Movie relationship 


Movie 

Director 

Director getDirector() 

Collection getMoviesQ 

I 0 ? 1 



① Define an ejb-relation between two beans 

<ejb-relation 〉 


° hC 代 Wiohshil 


© multiplicity for this bean 

<multiplicity>One</multiplicity> 


^y^ALL/ shouldhave ^4' s< ^ 

(a) Define an ejb-relationship-role for one bean 

<ejb-relationship-role> 

<e jb-relationship-role-name>DirectorBean</ e jb- relationship- role -name> 

chlilse V'talliZ 5 —卜 Wh “ ， 

\i o , w have called 

pa^i£i P a„i Jl'lt ^Iktg aUi hai ^ l，S US whi£h 

iWls d H0J Kow ^ ^ 

of Tm bea, -the OTHER will Jve. 

/Wov.c will Kavc Ohly OHB DwtcW 

VVc C^y\ use d^y vole—hSw'C >wc y/ajrrt, but 
sooner or latcv- -tKc Coy\ia'mc\r must kr\oy; 
EXACTLY bca 於 wcVc ialki^ about 

pu 七七 he bca^s <cjb-^amc> is j^-t < 

label -tcll'mg Uc Corrba_mc\r >^c\rc *to “d 
栎 is bed^s real m Uc <c^c\rp\risc- 

bedr\s> scd*tior\ o-f PP- TKis MW£T 

md'bdK d)r\ <cjb—Jr\3mC> *t^C PP. 

® cmr-field for this bean 

<cmr-field 〉 丁匕 . . 

<cmr-field-name>movies</cmr-field-name〉; ！mS 咖 a victual -picld^ ih *tKc 

bcah dlass -fom gc-tMovicsO / seiMoviesO 

<cmr—field—type> java .util.Collection< / cmr—field—type> 

</cmr-field> 


② source for this bean 

<relationship-role-source> 

<ejb-name>DirectorBean</ejb-name> 
</relationship—role—source> 



d 


@ cascade-delete for this bean 

(not specified for this bean) 

</ejb-relationship-role> 


Use <^mv-Pi c |d-typc> OHLy \( -tKc o-tKc^ 

Kas a /HAW ^\aho^\ ? h> this 

bca ^ 讪以 似 丫如 wiiUoid mo 代仏釙 

Ohc, so you y^ttA a Collc^ioh. /ou dah also 

sa y Xil.Set fy 财 o h |y t wo 


388 Chapter 7 








entity bean relationships 


(a) Define an ejb-relationship-role for the second bean 


<ejb-relationship-role> 

<ejb-relationship-role-name>MovieBean</ejb-relationship-role-name> 


① multiplicity for this bean 

<multiplicity>Many</multiplicity 〉 



iWis is just a hamc 4^ 
youv- owh U ihc App Assemble ov^ a 
tool s) use. li mcahs hotKihg \y\ youv- 

匕 ode. 


② source for this bean 


以 ㈣ 似 Will 

仏 =5 Si ， ㈣ 吻 


<relationship-role-source> 

< e j b-name >MovieBean< / ejb-name> 
</relationship-role-source> 


TKis m£T <C\b^ C > 4^ 

f 辦 you d^i^d tKc /Hovic 

DP 々一 ㈣ 士釙分 冰七伽 


® cmr-field for this bean 


<cmr-field> 

<cmr-field-name>director</ cmr-field-name> 
</cmr—field> 


@ cascade-delete for this bean 


<cascade-delete /> 


</ejb-relationship-role> 


Put this ih i-p you \w3rrt TH/£ 
kh io be deleted wKchcvcv its 

pav*thc\r is deleied. 


L 。上 ..… 切 ? We “’t d 

C。、— 

Md -切? 夕 


</ejb-relation> 
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ir^irpen your pencil 


Here’s the relationship DD for Director-to- 
Movie, but we’ve left a few things out. See if 
you can fill them in correctly without looking 
on the previous pages! 


Pirector-to-Movie relationship 




〈 relationships 〉 

<ejb-relation> 

<ejb-relationship-role> 

<e jb-relationship-role-name>_</e jb-relationship-role-name> 

〈 multiplicity 〉 〈 /multiplicity 〉 

<relationship-role-source> 

<ejb-name>DirectorBean</ejb-name> 

</relationship-role-source> 

<cmr-field> 

<cmr - field-name 〉 _</cmr—field - name> 


</cmr-field> 

</ejb-relationship-role> 

<ejb-relationship-role> 

<ejb-relationship-role-name>MovieBean</ejb-relationship-role-name> 

〈 multiplicity 〉 _ 〈 /multiplicity 〉 

<cascade-delete / > 

<relationship-role-source> 

<e jb-name>_</e jb-name> 

</relationship-role-source> 


</ejb-relationship-role> 
</ejb-relation 〉 

</relationships 〉 
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Does this mean that when 
a bean is in a relationship, it 
MUST have a field for the other 
bean? What if I want Movie to have 
a Trailer, but I don’t want anybody 
to use Trailer to get to a Movie? 



Movie 

_^ 

Trailer , 

Trailer getTrailerQ 

II no reference to Movie 

- r 

i i 


Relationships can be one-way 
(unidirectional) 

You can have a relationship between two 
beans, but have a CMR field in only one of 
the two beans. For example, if you set up a 
relationship between a Movie and its Trailer 
(a one-to-one relationship), and you don’t 
want clients to use a Trailer to get to a Movie, 
just leave the CMR field for Movie out of the 
Trailer bean. Simple as that. 

In that case, the TrailerBean won’t know 
anything about the MovieBean, even though 
they’re both partners in a relationship. 


<ejb-relationship-role> 

<ejb-relationship-role-name>TrailerBean</ejb-relationship-role-name> 
<multiplicity>One</multiplicity 〉 

〈 cascade—delete /> 


<relationship-role—source> 

<ejb-name>TrailerBean</ejb-name> 
</relationship-role-source> 
<cmr^i^ld> ✓ 

<cmr-fie^^^r^me></ cmr-field-name> 
</cmr-^r^Td> 

</ejb-relationship—role> 


Leave field out of a 

v-clatiohsKip ^olc i-f you do^i waht 
仏 is -to Kavc a 代 *to 

pa\rthcv* bea^. 
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directionality in relationships 

The dark side of a unidirectional (one-way) relationship 



Movie 



Trailer 



Movie 



Trailer 




Movie 




Trailer 




Movie 




Trailer 


Movie 



Trailer 
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Cascade delete caw propagate 




Director 


Movie 



Trailer 


l?irector-to-Movie Movie-to-Trailer 

relationship relationship 


Director (can't cascade-delete) 

Movie - <cascade-delete/> 

You can't set cascade-delete for the Director 
bean in the Director-to-Movie relationship, 
because Movie has a multiplicity of Many. Think 
about it... if someone deletes a Movie, should 
that Director be deleted? Of course not! The 
Director could still be the Director of other 
movies that still exist. 

But... the Director has a multiplicity of One 
with the Movie, so the Movie bean can say,、'I 
can have only one Director, so if he goes, I go." 


<^M 

Director 


Movie - (could cascade delete, but doesn't 
want to) 

Trailer- < cascade - delete/ > 

Because this is a one-to-one relationship, both 
partners could set a cascade-delete. But we 
want it to go in only one direction, where 
deleting the Movie deletes the Trailer, but 
not the reverse. Just because the Trailer 
is deleted does not mean we want the Movie 
deleted, but thafs determined by our business 
logic, and not EJB rules. 



Movie Trailer 


aDirector.remove() 

- ^ 


aMovie.removeQ ’ 

Director Movie 



Trailer 



Director 


Movie 


aTrailer.removeQ 、 



Trailer 
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relationships in the deployment descriptor 

The abstract schema is \v\ the <ewtity> element and the 
<cjb-relatiow> is iw the relationships) element 


<ejb-jar> 

<display-name>MovieJar</display-name> 

<enterprise-beans> 

<entity> 

<display-name>MovieBean</display-name> 

< e j b-n ame >MovieBean< / ejb-name> 

<local-home>headfirst.MovieHome</local-home> 
<local>headfirst. Movie</local> 

<ejb-class>headfirst.MovieBean</ejb-class> 
<persistence-type>Container</persistence-type> 
<prim-key-class>java.lang.String</prim-key-class> 
<reentrant>False</reentrant> 

<cmp-version>2.x</cmp-version> 

<abstract- schema-name>MovieSchema</ abstract-schema-name> 
<cmp-field 〉 

<field-name>genre</field-name> 

</emp-field 〉 

<cmp-field 〉 

<fie 1 d—name >movie ID< / fie 1 d - name > 

</emp-field 〉 

<cmp-field 〉 

<field-name>year</field-name> 

</emp-field 〉 

< emp-field 〉 

<field-name>title</field-name> 

</emp-field 〉 

<primkey—fie ld>movi el D</pr imkey—field 〉 

〈 security-identity 〉 

<use-caller-identity></use-caller-identity> 

</security-identity 〉 

</entity> 




."广 schema +OV- pcv-sistcht 

7 lds HERE ih ihc <My> 

e Uhdcv <Ch-tc\rp\risc-bcahs> ; 

all art des^ibed. 

elects 

iz<M> ww 卿 c 十 cd 

t\\t 7 • 一 Wips> sedW 


<entity> 

<display-name>DirectorBean</display-name> 

<ejb-name>DirectorBean</ejb-name> 

<local-home>headfirst.DirectorHome</local-home> 
<local>headfirst. Director</local> 

<ejb-class>headfirst.DirectorBean</ejb-class> 
<persistence-type>Container</persistence-type> 
<prim-key-class>java.lang.String</prim-key-class> 
<reentrant>False</reentrant> 

<cmp-version>2.x</cmp-version> 

<abstract-schema-name>DirectorSchema</abstract— schema-name 〉 
< emp-field 〉 

<field-name>name</field-name> 

</emp-field 〉 
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<cmp-field 〉 

<field-name>winner</field-name> 

</cmp-field 〉 

<cmp-field> 

<fie 1 d-name>directorID</ fie ld-name> 


</cmp-field> 
<cmp-field 〉 


<fie 1 d—name >degrees</ fie 1 d- name > 

</cmp-field 〉 

<primkey-field>directorID</primkey-field> 


〈 security-identity 〉 

<use-caller-identity></use-caller-identity 〉 
</security-identity 〉 

</entity> 

</enterprise-beans> 


〈 relationships 〉 

<ejb-relation> 


(a,d ail ^ b , SC s 


<ejb-relationship-role> 

<ejb-relationship-role-name>DirectorBean</ejb-relationship-role-name> 


<multiplicity>One</multiplicity 〉 
<relationship-role-source> 

<e j b—name>DirectorBean</e jb-name> 
</relationship-role-source> 
<cmr-field> 


Ch*tev-pv-isc-bcahs> scd-tioh 


<cmr-field-name>movies</ cmr-fie ld-name > 


<cmr—field—type>j ava . util. Collection</cmr-field-type> 
</cmr-field> 

</ejb-relationship-role> 


<ejb-relationship—role> 


^ - <^^-Pidd-ty P c> is o,ly wheh youv ?a ^ (^i 


<ejb-relationship-role-name>MovieBean</ejb-relationship-role-name> 
<multiplicity>Many</multiplicity> 


<cascade-delete /> 夭 - 

<relationship-role-source> 

< e j b-n ame >MovieBean< / ejb—name> 
</relationship-role-source> 
<cmr-field> 



MovicBcah says, You ^ 
whch y° u delete my 




<cmr-fie 1 d-name>director< / cmr-fie ld-name> 

</cmr-field> 

</ejb-relationship- roie> a u . c> 七 Pive^tov has a 

</e. b -re latl on> 5 ^ 

〈 /relationships 〉 or\^ ov\t Pivc^-tov-, v>o 


"S- 
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Movie^ean code with a CMR field 


package headfirst; 

import javax.ejb.*; 
import j avax.naming.*; 
import java.util.*; 

public abstract class MovieBean implements EntityBean { 
private EntityContext context; 

public String ejbCreate(String movielD, String title, int year,String genre, 

String directorlD) throws CreateException { 

setMovielD(movielD); 
setTitle (title); 
setYear (year); 
setGenre(genre); 
return null; 


. oU , ㈣ sW Wds, W 6 L all T', 


public void ejbPostCreate(String movielD, String title, int year, String genre, 

String directorlD) throws CreateException { 

try { 

工 nitialContext ctx = new InitialContext (); 


DirectorHome dirHome = (DirectorHome) ctx.lookup(''java:comp/env/ejb/DirectorHome") 
Director dir = dirHome• findByPrimaryKey(directorlD); 
setDirector(dir); 


catch (Exception ex) 

{ / /handle exception} 



Now |£ s sa-Pc -to assi^h ouv pcvsis-tcht v-clatiohship 

J idd ^ lookup iUc VwttboY (usma 

the d'Hrcd-to\r|P pavametev -from dveate) dal I ouv 

^bsxV'^d't settev *to -this Divcd*tov. 


public String ejbHomeListMoviesByDirectorAndGenre(String dirlD, String genre) 
String list = null; 


try 


Collection c = ejbSelectGetMoviesByDirectorAndGenre(dirlD, genre); 
Iterator it = c.iterator (); 
while (it.hasNext ()) { 

list += it.next (); 


, u A i oX ^ 


catch (Exception ex) 
return list; 


ex.printStackTrace() 
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public String ejbHomeListAHMovies () { 

String list = null; 
try { 

Collection c = ejbSelectGetAHMovies (); 
Iterator ita = c.iterator (); 
while (ita.hasNext ()) { 

Movie movie = (Movie) ita.next (); 
list += '' '' + movie . getMovieTitle (); 



} catch (Exception ex) 
return list; 


// handle exception} 


all w ov\cs. TW»s a 

Collet adW H 


public String getMovieTitle () { 

return getTitle (); 


Two exposed business methods -fvom 
七 lie dompohCh*t … 

〆 


public String getMovieDirectorName() { 

return getDirector () .getDirectorName(); 


public abstract String getMovielD(); 
public abstract void setMovielD (String i) 

public abstract String getTitle(); 
public abstract void setTitle (String t); 

public abstract int getYear(); 
public abstract void setYear (int y); 

public abstract String getGenre(); 
public abstract void setGenre (String g); 

public abstract Director getDirector(); 


Wc hdvc F|\/E vivtual -fields-- 

-fou^r C/WP fields av\d 

OhC CAlR -field -Pov- Pivcd*tov-. 



public abstract Collection ejbSelectGetAllMovies () throws FinderException; 


public abstract Collection ejbSelectGetMoviesByDirectorAndGenre (String dir, String 
genre) throws FinderException; 


public void unsetEntityContext() 

public void ejbLoad() { } 

public void ejbStore() { } 

public void ejbActivate() { } 

public void ejbPassivate() { } 

public void ejbRemove() { } 


丁心七如 。 select methods av-c declared as 
^bs-tv-adt wtliods. "Hie Collcd*tioh doesy /七 say 
the mc*thods will … bu*t we’ll 七 e" 
Co^ia\^ that ohc will a Collcdtioh 

°** Movies 3hd OhC d Collcd*tioh o-P £"tv*ih^s. 


public void setEntityContext (EntityContext ctx) 
context = ctx; 


The v-cs*t av-c 
v-cgulair old dallbddk 
w'Cxhods. 
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The Movie^ea^s home interface 


import javax.ejb.*; 
import java.util.*; 
import java.rmi.*; 


public interface MovieHomeRemote extends EJBHome { 


public MovieRemote create(String movielD, String title , int year, String genre, 

String directorlD) throws CreateException, RemoteException; 

public MovieRemote findByPrimaryKey(String key) throws FinderException, 

RemoteException; 

public Collection findByGenre(String genre) throws FinderException, RemoteException; 


public String listAHMovies() throws FinderException, RemoteException; 

public String listMoviesByDirectorAndGenre(String directorlD, String genre) 

throws FinderException, RemoteException; 

public Collection findMoviesByKevinDegrees(int degrees) throws FinderException, 

RemoteException; 


^ d0h ^ ^ 

/，加亂/ m d ：: b —. 

L 广 e 


从 at 


丁 k 
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And what 
about the Finder 
methods? I can understand 
how it can do findByPrimaryKey, 
because it already knows the 
key, but what about the 
others? 


And while I'm 

at it... HOW DOES IT KNOW 
WHATYOUR FIELDS MAP TO 
IN THE DATABASE?! How do you 
link your abstract schema to real 
database tables and columns? 
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Mapping from abstract schema to a real database 


Sooner or later, you have to tell the Container how and where to manage your 
persistent data. This happens outside the deployment descriptor, in a vendor- 
specific way. That means, of course, that you’re not tested on it in the exam. Every 
vendor has their own mechanism, but you’ll usually get some sort of a GUI where, 
if you’re lucky, you can tell the Container to connect to a specific database, and 
then you’ll drag and drop or draw connections from CMP fields to columns in 
one or more tables. 

Because this mapping happens outside of EJB, in the server, there’s not much 
we can say about it. The part we’re most interested in is mapping from abstract 
queries to REAL queries, and that happens in a very cool way, using a vendor- 
independent query language just for your entity bean queries, EJB-QL. We’ll look 
at that on the next page. 


<abstract-schema-name>MovieSchema</abstract-schema-name 〉 


<cmp-field> 

<field-name>genre</field-name> 

</cmp-field 〉 

<cmp-field> 

<field-name>movieID</field) oame> 

</cmp-field 〉 

< cmp-fie Id 

<fie ldyname >year< / fie 1 d- name > 

</cmp-fj4ld> 

<cmp-f/eld> 

<fie^.d-name>title</field-name> 

</cmp - -field> 

<primRey-field>mo 「 ieID</primkey—field 〉 







MovielD 

Title 

Genre | 

DirectorlD ^ 

Year 

12 

Crouching Pixels, Hidden Mouse 

Action 

^ - ’ 

2000 

5 

The Fifth Array Element 

Action 

27 

2003 

22 

The Return of the Bean Queen 

Fantasy 

27 

2001 

11 

Lord of the Loops 

Sci-fi 

42 

2002 
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Writing your portable queries, for select awd fiwder methods 


Remember, I’m a 
programmer, so the less I 
know, the happier I am. With 
EJB-QL, I don't have to know 
anything about the real database 
where my bean will end up 
running. 



EJB-QL is a portable query language that lets you 
write SQL-like statements write into the deployment 
descriptor! You put them in the XML and without 
having to know anything about the real database. 

As a Bean Provider, you can happily write all the 
queries you want, trusting that the Deployer will, in the 
end, map your CMP fields to real tables and data. All 
we care about here is writing our queries to match the 
methods we’ve chosen to expose to the client in the 
home and component interfaces. 

Select methods are here simply to make your life 
easier, by letting the Container build the real database 
access code from your queries. 

So the process is usually something like: 

1. Write a home business method 

2. Implement the home business method to call 

the ejbSelect method that does the real data access. 

3. Declare the abstract select method in your bean 
class. 

4. Write the EJB-QL for the select query. 
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EJB-QL queries 


QL for the Movie^ean 

Let’s look at the EJB-QL for all the queries the MovieBean needs. Don’t worry if you’re 
not understanding all of it; after we walk through the examples, we’ll explore the 
different pieces in detail, and work out the syntax. If you know SQL, most of this will be 
familiar (although there are few differences you’ll see). If you don’t know SQL, that’s 
OK. We’ll get you started writing queries, and you can use the spec to learn more about 
the EJB-QL language. The exam expects you to know just the basics of EJB-QL. 

In the bean class 

public abstract Collection ejbSelectGetAHMovies() throws FinderException; 




丁二 


In the the deployment descriptor 

SELECT OBJECT (m) FROM MovieSchema m 


Th — %“ whW V 

/, -thisV is 制 

^ IVC /vj ovic 


' ^ 一 . aWc 


What it really says 

''Give me all the Movie beans” 
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Using an optional WHERE clause 


This example constrains the objects returned from the search, by adding a WHERE 
clause that says what extra criteria the objects have to meet before they qualify for 
“things that can be returned from the query.” The WHERE clause is your way of 
saying, “Don’t just give me ANY old Movie... I want ONLY the movies that...” 




In the bean class 


CoWtc^ 


public abstract Collection ejbSelectGetAHMovies() throws FinderException, 


In the the deployment descriptor 

SELECT OBJECT (m) FROM MovieSchema m 
、-- ， - / 

K ^ hS /V(ov\c fccav' ^ 

ou t to be... 



I/Vhat it 


really says 

“Give me all the Movie beans that are in the 
genre matching the first parameter to the 
ejbSelectGetAIIMovies method.” 


' se ^T () 

"this \n\c3iy\s -the 
"to -the method 

wa UV.es Wt?^^ ^ 

se\ett 州也 0 j ^scs tV.c M 

一知 。 f 二如 -^ 

从 at … 呼 ^ 丄 “ o?— d 

\s a ^ V，^ tv?c . ItsaWost 

sa v/, 'V'fMov^ y ^ 

— 如沘祕 .） 
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path navigation 


Navigating to another related bea^ 


This example is for a finder method, so you won’t find it in the bean class 
(remember, you declare abstract methods for only the select methods, not the 
finders. The Container uses your home interface to figure out what the finders are, 
and then it’s up to you to write the EJB-QL for the finders). 

You can use the dot operator to navigate not just to a CMP field in the bean, but to 
another field within a bean referenced in a CMR field. In other words, If Movie has a 
reference to a Director (and they’re in a relationship), you can use the Movie to get 
to the Director to ask for a CMP value from the Director. 

In the home interface 

public Collection findMoviesByKevinDegrees(int degrees) throws FinderException, 

RemoteException; 



In the the deployment descriptor 


SELECT OBJECT (m) FROM MovieSchema m WHERE m.director.degrees = ?1 



What it really says 


“Give me all the Movie beans that have a Director 
whose degrees match what the client sent in to 
the finder method.” 

OR 

“I want to get Movies back, but only those Movies 
directed by someone who is a specific number 


of degrees away from Kevin Bacon. 


Six degrees from Kevin Bacon is a popular game 
where you try to take a Hollywood type and see 
how many connections it takes to get that person 
linked to Kevin Bacon.” 
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Selecting a value rather thaw the whole bea^ 

This example is for a home business method that takes two parameters 
and returns not Movies, but Strings. 


In the home 
interface 





public String ejbHomeListMoviesByDirectorAndGenre(String dirlD, String genre) 


In the the deployment descriptor 

*B)is is lA/cVc jus 七 

Movie titles, ho*b Movie objcd*ts 

~N 

SELECT m.title FROM MovieSchema m 




WHERE m.director.directorID = ?1 


m.genre = ?2 


This 




AHV whose Movie 5C^\rc value equals the 
second pav-ametev -to -the method 


What it really says 

“Give me back Movie titles (Strings) that have 
the director and genre I specified in the method 
arguments." 
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EJB-QL SELECT 


m-Ql SELECT 


Now that you’ve seen some queries, we’ll look at some of the details and rules. 

Query Domains 

The domain of a query is a single deployment descriptor. So that means a single ejb- 
jar file. However many beans you can squish in the ejb-jar, that’s how many beans you 
can search across. 

SELECT 

The SELECT clause says what kind of thing this query will return. 

It can be only one of these two: 


① an abstract schema type for an entity bean 


<abstract-schema-nam^>MovieSchema^/abstract-schema-name> 


SELECT OBJECT (m) FROM MovieSchema m 


OR 


(D a <cmp-field> single value type for an entity bean 


㈤工峰 3 

-t ， 


<cmp-field 〉 

<field-nam^>title<y field—name> 

</cmp -fie 1 d> \_ / 

SELECT m. title FROM MovieSchema m 


You can，t use dot notation to 
return a CMR field! 

Asa SELECT type, these are OK: 

m. title or m.genre 

But this is NOT OK: 

m. director 

You can use a CMP field, but not a CMR field with 
the dot notation, as the SELECT type. 


you use a — *field> 
o( a variable ； we 

匕 a 11 "this a s'mjlc—valued 

CXp\rcssioh. 

h/OTB ： wcVc deviating 

s-bhdavd 匕 cmwtiohs m 

ouv * bc^usc 

， Wht i 七托 be OBVIOUS that 

wcVc usi 吒七 k hamc ahd hoi 

兑 y, ihc bcah hamc. |h tKc tKc 

abs-tvad-fc schema hdme is same 
as the ^ompohCh*t v\a^ 
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entity bean relationships 


WP - QL SELECT — whew to use Object () 

What’s with the OBJECT (m) thing? 

It’s a structure the J2EE designers put in to be consistent with a 
version of SQL. 

It’s annoying. 

But you have to do it whenever you return a bean type instead of a 
CMP field type. And you must NOT do it whenever you return a 
CMP field type. 


If you return the bean’s abstract 
schema type, use OBJECT( )■ 



<abstract-schema-name>MovieSchema</abstract-schema-name> 


SELECT OBJECT (m) 


If you return a <cmp-field> 
don't use OBJECT () 

<cmp-field 〉 

<field-name>title</field-name> 



</cmp-field> 


SELECT m.title 

A , , . dot, ^ 


e^arpen your pencil 

Cirr.lfi thfi F. 


Circle the EJB-QL statement if it has a legal SELECT clause 


SELECT OBJECT (m) FROM MovieSchema m 


SELECT m.title FROM MovieSchema m 


SELECT m FROM MovieSchema m 


SELECT OBJECT (m.title) FROM MovieSchema m 
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EJB-QL SELECT 


What does it AN to return aw 
abstract schema type? 


The abstract schema is just a stupid 
label in XML, so obviously THAT is not 
what you re returning. You re returning the 
bean type. But that cant be right either... you re 
obviously returning the component interface type, 
but THAT cant be right because how would it 
know if ifs supposed to give you the local 
or Remote type... 


% 




The MovieSchema abstract schema name 
represents the bean type. 

As if by magic, the Container knows which 
interface view to return, local or Remote, 
depending on whether the invocation of the 
query came from a home or Remote interface. 



MovieLocal 


MovieRemote 

1 Yova 

to …叫 aV) °7 

getMovielD() 


getMovielD() 

getTitle() 


getTitle() 

\ota\ ov 

getGenre() 


getGenre() 

getDirector() 

getTrailerQ 


getDirector() 

getTrailer() 


When you see this: 

MovieSchema m 

Think this: 

m = the component interface 

(and we’ll let the Container sort out the 
Remote vs. local issue) 
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entity bean relationships 


SEUCT awd FROM arc wawdatory! 


You gotta have SELECT and FROM no matter what, but the WHERE 
clause is optional. With SELECT, you can also use the keyword DISTINCT 
to say that you don’t want any duplicates returned in your Collection. 


use 


vt 


dc£ ， ls\rc i-t 





SELECT DISTINCT OBJECT (m) FROM MovieSchema m 


PISTINCT 州广 s 

V dvA?V^aW ， 


^ ihj FROH wc ded ^ c ihc 
•aCJvtiTi^a-tioh vav-iable 
thais used ih -the SBLBCT. 


The FROM clause declares the identification variable (like the “m” in our 
example query). This also defines the domain of the query by saying to the 
Container, “Here’s where I want you to be looking...” The order in which the 
FROM and SELECT might feel a little strange if you’re not used to SQL. But 
think of it like someone saying, “I want you to go get my things, and the things 
I’m talking about are FROM my top drawer.” 


If you need to declare more identification variables to use later in the query, 
you can separate them with a comma: 


SELECT OBJECT (m) 

FROM MovieSchema m, Direc tor Schema d 


those -two 




You can also use the AS keyword. It’s optional, but you might see it on the exam 
or in someone else’s code, or your company style guide might insist on using it. 
We’re too lazy to keep typing it. 


SELECT OBJECT (m) FROM MovieSchema AS m 
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Identifiers 


When you make an identifier, you have to follow the Java 
programming language guidelines for what you can name things. 
You can’t use the other Java identifiers 


Identifiers 


Must be valid Java identifiers 


Must NOT be same as an <abstract-schema-name> 
or <ejb-name> anywhere in the DD 

Must NOT be one of the EJB-QL reserved words 


EJB-QL 

reserved words 

SELECT 

OR 

FROM 

BETWEEN 

WHERE 

LIKE 

DISTINCT 

IN 

OBJECT 

AS 

NULL 

UNKNOWN 

TRUE 

EMPTY 

FALSE 

MEMBER 

NOT 

OF 

AND 

IS 


Watch out for 
questions with 
name conflicts! 

Remember thdt an <ejb-name> 
be unique for each bean in the ejb-jar, 
which means unique for one comp ete 
DD. The same is true for the <abstract- 
schema-name>; it must be unique in 
the DD. 

You already know that you can’t use an 
identification variable in your query that 
matches an <ejb-name> or obstract- 
schema-name> in the DD, but keep in 
mind that EJB-QL is not case-sensitive. 

So, you must NOT do this: 

SELECT OBJECT (movie) 
FROM Movie movie 

|h EJB - 夕 L, “Movie” is 七 he 
same Ss ) dhd you 

Uh’ 七 have doh-flidtihj hdmes. 


not used in the current version; it’s future use is unknown... 
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The WHERE clause 

A WHERE clause is optional, and let’s you put extra conditions on what’s 
returned. Remember that without one, we got everything of the type used 
in the SELECT. 


NOT using WHERE 

SELECT OBJECT (m) FROM MovieSchema m 


Existing Entities 



.Movie 

Movie Movie 


Entities returned 
from the query 



\Movie 


Movie 


\T 


Using WHERE 

SELECT OBJECT (m) FROM MovieSchema m 


a 

Wtcv-al 



WHERE m.genre = 'Horror A 



Existing Entities 




Movie 

Movie, 

Movie Movie 


Entities returned 
from the query 


、 Movie jvie 

Movie/ 






二 
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the WHERE clause 


The WHERE clause 


You can use literals 

WHERE m.director.degrees > 3 
WHERE m.genre = 'Horror A 

You can use input parameters 

WHERE m.director.degrees > ?1 

And the parameters don’t have to be in order... 
that’s why they have numbers! 

WHERE m.genre = ?2 AND m.director.degrees < ?1 

public String ejbHomeListMoviesByDirectorAndGenre(String dirlD, String genre) 


You can do comparisons 

WHERE m.director.degrees < 5 


But you better compare apples to apples 


WHERE m.director < 5 

, L … 狄 c a P .、 代如 

La，^ 一 6 沛 C . 
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The problem with using Collection types 


Imagine you want to use the DirectorSchema to return all the 
Directors that have made horror movies. Sounds pretty simple... 

Director has a CMR field for movies, and each movie has a CMP 
field for genre. So we come up with something like this: 

SELECT OBJECT (d) 

FROM DirectorSchema d tvA-t ^ ' 

WHERE d.movies . genre = 'Horror A (sJOT 


Why can’t you do this? 

Let’s back up and imagine this is Java code. How do you normally 
use the dot operator in Java? You might do something like: 


Owner o = new Owner(); 
o. getDogO . bark (); 

^ \ 

o-P 0 ^ ^od 


OYmev’s M 


The Owner has a getDogO method, and the Dog has a bark(). 
No problem. 

But what if we changed the Owner to allow one Owner to have 
multiple Dog objects? Then what happens... 


Owner o = new Owner(); 
o.getDogs().bark(); 

/ T 

ot?Co\\^••• 




void bark() 
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using collections in a path 


Collections dontbarkO! 


You can’t use the dot navigation when something you’re using 
in the path is a Collection. For example you can’t do this: 


Owner o = new Owner(); 
o.getDogs().bark(); 


T 娜從娜 I 


Owner 


Collection dogs 
Collection getDogs() 



It’s the Dog objects IN the collection that can bark()! So, in 
Java, you’d have to first access the individual Dog elements in the 
collection, and one at a time ask each Dog to bark(). The Dog code 
above is almost exactly like this WHERE clause we had before: 

认 o\\ 

WHERE d.movies.genre = 'Horror A 1 

And since “movies” and “genre” are virtual fields, 
with accessors, you can think of it just like this: 

d.getMovies().getGenre() = 'Horror A 




Think about it... what would you 
be trying to say here? That the 
whole collection has a genre? No, 
a collection doesn’t have a getGenreQ. 
It’s the movies in the collection that 
have a getGenreQ. So this syntax 
doesn’t make sense. 






Director 


Movie 

getDirectorlD() 
getOscarWinner() 
getDegrees() 
qetNam^D - - 

getMovielD() 

getTitle() 

getGenre() 

getDirector() 

getTrailer() 

getMovies()^> 

"""" 
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The IN operator lets you say 

"For aw individual element IN the Collection . 二 

The IN operator for the FROM clause let’s you refer to a 
Collection, but name an identifier as representing ONE 
member of the Collection. 


SELECT DISTINCT OBJECT (d) 

FROM Director Schema d, IN (d. movies) ml% 
WHERE m.genre = 'Horror A 


Koy/ “m’ \rcpv-csch*b dh mdividual 
Movie IN £Kc movies Collediioh 
(a CMR -field Pi\rCd*to\r) 


Dikiis 1 h wc said 1 術 inct 


r 二鄉 ▲ 

V>oid 崎） 


The IN operator is 
overloaded in EJB-QL! 

The IN operator in the FROM clause is differ¬ 
ent from the IN comparison operator used in a 

WHERE clause. 

In the WHERE clause, you can say: 

d genre IN (‘Horror’ ， t Fantasy , ) 
and it is just a shortcut for saying: 

d.genre = ‘Horror’ OR d.genre = Fantasy 

But it has nothing to do with the IN operator 
use d in a FROM clause to designate mdividu 
members IN a Collection. So just remember. 

FR OM clause: IN says, “Look at the individual 

obje l in the Coilection, and rather than using 

the Collection as the type, use the type of the 
items IN tho Collection, 

WHERE clause: IN says, "See if the f ' eld 
value matches one of the literals in this set … 
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EJB-QL BETWEEN 


The PtTWKN expression 


Let’s say you want to find movies in the database made in the 
60’s and 70’s, but you want to exclude any movies made in 1975 
or 1976, really bad movie years. 

You could say: 


SELECT DISTINCT OBJECT (m) 

FROM MovieSchema m 

WHERE (m.year > 1959 AND m.year < 1975) OR 
(m.year > 1976 AND m.year < 1980) 


Or, you could do it the cooler way: 


SELECT DISTINCT OBJECT (m) 
FROM MovieSchema m 


WHERE (m.year BETWEEN 1960 AND 1979) 

(m.year NOT BETWEEN 1975 AND 1976) 

… - 恤减 卿 _、 s ' N ' l T 
w — NOT 卿跡 


If Tm BETWEEN 
a rock and a hard place, 
both the rock and the hard 
place are INCLUDED. I 
bet you know the feeling. 
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entity bean relationships 


The other "IN 


We’ve used IN with a FROM clause to help navigate through 
collections, but IN has another personality, you might say IN 
has been overloaded for use in the WHERE clause. Let’s say 
that you want to select movies from a subset of all the movie 
genres in your database: 


SELECT DISTINCT OBJECT (m) 

FROM MovieSchema m 

WHERE m. genre IN ('horror A f 'mystery') 




^OVA 




ated 如 *^ e 神 ^ 


And there’s always NOT IN for those times when 
you need some action: 

SELECT DISTINCT OBJECT (m) 

FROM MovieSchema m 

WHERE m. genre NOT IN (' romance ' r ' comedy A 

"This ^ucv-y would v-ciuv-h ohly 
"those movies whose gchv-c is 
NOT ov- u domcdy w 


«!=” is NOT the 
same as M < > w 


/hen comparing values in a 
/HERE clause, “ means not 

quals”. You use THAT instead of 

=» But coming from Java, that 
an look so right... when you see it 
)n a question. Don’t be tempted. 


a *e Hf s!ngII 

〜〜 r tes - r 
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IS EMPTY 


The IS tMPTY comparison expression 


This baby will let you know whether the collection in question 
is empty: 


SELECT DISTINCT OBJECT (d) 
FROM DirectorSchema d 
WHERE d.movies IS EMPTY 


Just show 
me the losers who 
haven’t made any 
movies... 


TW»s 







The IS NOT EMPTY comparison expression 

IS NOT EMPTY lets you say, “Don’t give me anything where this 
field is empty...” 


SELECT DISTINCT OBJECT (d) 
FROM DirectorSchema d 
WHERE d.movies IS NOT EMPTY 


代 W — 乂 铣 f 二 
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The LIKE expression 


Like expressions are used to compare single value path 
expressions with a String literal. The power of LIKE is that the 
String literal can have wildcard elements, giving you a simple 
pattern matcher. The “％” wildcard matches against 0 to many 
characters; the matches against a single character only. 


SELECT DISTINCT OBJECT (d) 
FROM DirectorSchema d 
WHERE d.phone LIKE '719V 

， ( 7/f With ihc 




rd 


SELECT DISTINCT OBJECT (m) 

FROM MovieSchema m 

WHERE m. filmcode LIKE '7 mm' 


㉝ 






The NOT LIKE expression 

SELECT DISTINCT OBJECT (m) 

FROM MovieSchema m 

WHERE m. filmcode NOT LIKE 、％ mm, 

tr ㈣ 碑二 es 

PON’T 一 … • 
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BULLET POINTS 


% 


■ Entity beans can have persistent relationships with other 
entity beans. 

■ A container-managed relationship (CMR) field is defined 
in the bean class just as a CMP field is—with a pair of 
abstract getters and setters that return either the local 
component interface of the bean, ora Collection. 

■ If the virtual field is a Collection, it must be declared as 
either java.util.Collection or java.util.Set. No other Collec¬ 
tion type is allowed as the declared return type of a CMR 
field. 

■ Relationships have multiplicities—they can be one-to- 
one, one-to-many, or many-to-many. (Many-to-one works 
in the same way that one-to-many works; it just depends 
on whose point of view you’re using.) 

■ For example, a Movie bean has a many-to-one relation¬ 
ship with a Director bean. Each Movie has only one 
Director, but a Director can have many Movies. 

■ Multiplicity affects the return type of the virtual field. 

Movie has only one Director, so the CMR field in the 
bean is getDirector(), that returns a reference to a 
Director’s local component interface. But a Director has 
many movies, so a Director’s virtual field is getMovies(), 
which returns a Collection. 

■ A CMP bean must define an "abstract-persistence-sche¬ 
ma in the DD, that lists each of the bean’s CMP fields, 
and also identifies which of the fields is the primary key 
(unless it’s a compound primary key). The DD must 
always define the type of the primary key, even if the 
primary key is not a field of the bean. (Remember, if the 
primary key is not a field of the bean, it must be a pri¬ 
mary key class composed of CMP fields from the bean.) 

■ Relationship (CMR) fields are not defined in the <enter- 
prise-bean> portion of the DD (where you define your 
CMP fields), but are instead defined in the 〈 relation- 
ships> section of the DD. 

■ Each relationship must have two partners, with each 
partner described in an <ejb-relationship-role> element 
that includes the CMR field name, the source (<ejb- 
name>) for the partner, the multiplicity (i.e. how many of 


this bean will the other partner have), and an optional 
<cascade-delete/> (which says, “Delete me if my partner 
is deleted.” 

■ Relationships can be one-way (unidirectional) or 
two-way (bi-directional). A unidirectional relationship is 
described in the DD in the same way as a bi-directional 
relationship, except that only one of the two partners 
has a CMR field. This means bean A has a reference to 
bean B (they’re in a relationship), but bean B does not 
have a reference back to A. Directionality does not affect 
multiplicity or cascade-delete; it just means that only one 
of the two partners has a reference to the other. To the 
Container, they’re still in a relationship. 

■ Cascade-deletes tell the Container to delete the bean 
with the <cascade-delete/> tag when the bean’s partner 
is deleted. This works only if the bean has a multiplic¬ 
ity of one. (You wouldn’t want to delete a Director just 
because one of this Movies was deleted; but you might 
want to delete a Movie if its sole Director was deleted.) 

■ A bean cannot access its CMR fields in ejbCreate(); it 
must wait until ejbPostCreate() before, say, assigning 
the CMR virtual field an actual value. In other words, you 
can’t use your abstract getters and setters for your CMR 
fields until after ejbCreate() completes. 

■ EJB-QL is a portable query language you can use to 
specify your queries for both finder and select methods. 

■ In an EJB-QL query, the SELECT and FROM clauses 
are required; the WHERE clause is optional. 

■ A SELECT can return either an <abstract-schema-type> 
(which really means the bean’s local component inter¬ 
face type), ora single-value field. 

■ If you use the dot notation for navigating a path (for ex¬ 
ample, m.genre), you can’t use a Collection type as part 
of the path. To use a Collection type as part of a FROM 
clause, you must enclose it using the IN(d.movies) 
operator. 
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Relationship assignments 

A Movie can have only one Director. If you set a 
Movie’s Director field to Director 1, the Movie 
will be in Director l’s collection of Movies, but 
in no other Director’s collection. If you later 
reassign the Movie’s Director field so that the 
Movie has a different Director — Director 2 — the 
previous Director (Director 1) will no longer 
have that Movie in its Collection. 

This all happens automatically! To maintain the 
integrity of the database, the Container manages 
both sides of the relationship at all times. 



Director 1 Director 2 


Before: 



Director 1 l*s Movie Collection. If you 


call getDirector() on any of 
these Movies, they will return 
Director 1. 



There is only one Movie 
in Director 2's Collection. 
Ifs the only Movie that 
will return Director 2 if 
you call getDirector() on 
the Movie. 



Director 2 


movieA.setDirector(movieD.getDirector()); 4^ 


After: 



Director 1 





MovieA 


Movie A can have only one Director, so when 
we reassigned the Director for Movie A to 
be Director Z, Movie A was automatically 
REMOVED from Director 1's Collection of 
Movies. Remember, the Container manages 
both sides of the relationship! 


When we reassigned the 
Director of Movie A, that Movie 
automatically moved into Director 
2's Collection of Movies. 



Director 2 
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assignments in relationships 


If the woltiplicity of the relationship field is ONE, if s a MOVE 
If the multiplicity is MANY ifs a COPY " 

<ejb-relationship-role-name>MovieBean</ejb-relationship-role—name> 
<multiplicity>Many</multiplicity> 

<ejb-relationship-role-name>DirectorBean</ejb-relationship-role-name> 
<multiplicity>One</multiplicity 〉 

When we assigned Director 2 to Movie A, the Movie moved from Director 1 ’s Collection to 
Director 2’s Collection. The Director CMR field has a multiplicity of One in its relationship 
with Movie, so a Movie can’t exist in the Collection of two different Directors, because a 
Movie can have only One Director. 

But just because we move the Movie, doesn’t mean the Director also moves. The 
multiplicity of Movie is Many, so when you assign another Movie’s Director to a different 
Movie, that Director reference is copied, and both Movies will now have a reference. 


The MOVIE reference was MOVED from one Director to another 


movieA. setDirector (movieD.getDirector ()); 



Because the Director-to-Movie relationship is One-to-Many, a 
Movie can NEVER exist in more than one Directors Collection. If 
you change a Movies Director, the Movie is not copied! It is moved 
to the new Directors Collection. 


Director 2 




The DIRECTOR reference was COPIED from one Movie to another 




Director 2 



Director 2 




P ，s 


時 山⑽七 一 ved . 


422 


Chapter 7 









entity bean relationships 




Multiplicity and Assignments 


Given this relationship: 

<ejb-relationship-role-name>MovieBean</ejb-relationship-role-name> 
<multiplicity>One</multiplicity 〉 

<ejb-relationship-role-name>TrailerBean</ejb 一 relationship — role—name> 
<multiplicity>One</multiplicity 〉 



Draw what the picture will look like after you run: 

movie1.setTrailer(movie2.getTrailer()); 


P^rdvi '/ouv 

06 We 


Answer these questions: 


What is the result of: 
What is the result of: 
What is the result of: 
What is the result of: 


movie1•getTrailer() 
movie2.getTrailer() 
trailer A. getMovie () 
trailerB.getMovie() 
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exercise solution 



Multiplicity and Assignments 


Given this bi-directional relationship: 


<ejb-relationship-role-name>MovieBean</ejb-relationship-role-name> 
<multiplicity>One</multiplicity> 

<ejb-relationship-role-name>TrailerBean</ejb-relationship-role-name> 
<multiplicity>One</multiplicity 〉 


And this current scenario: 




Movie 2 


Draw what the picture will look like after you run: 

movie1.setTrailer(movie2.getTrailer()); 



Movie 1 



Answer these questions 

moviel.getTrailer() 

movie2.getTrailer() 
trailerA. getMovie () 


/l/lovie has a multiflidi-ty of O^t, so a T\railcv have 
oh |y ONE /^ov.c. A Tvailcv be with both Movie I and 2- 

also rcW r^ull... Trailer has a -I 七中 0^ so 

be O^lv Tra-.l^ ^ /l/l 。 汝屬〒 T^a-.lc^ to Move h 

disdo^cd-tcd Wov^ the vela 七 umsh.f. 
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What’s true for an entity bean provider using container-managed persistence 
to create persistent relationships? (Choose all that apply.) 

Q A. A local interface is required for such a bean to have a bidirectional 
relationship with another entity bean. 

Q B. Such a bean can have relationships with only session beans. 

口 C. Relationships can be only one-to-one or one-to-many. 

[I D. A getter method return type can be java.util.List. 


What’s true for an entity bean provider using container-managed persistence 
to create persistent relationships? (Choose all that apply.) 

Q A. A remote interface is required for such a bean to have a bidirectional 
relationship with another entity bean. 

Q B. Such a bean can have relationships with only message-driven beans. 

Q C. A get method return type can use java.util.Map. 

口 D. Relationships can be one-to-one, one-to-many, or many-to-many. 


3 


When a remote client invokes a method on an entity bean using container- 
managed persistence, and that bean has already been removed, what 
exception will be thrown? 


□ 

A. 

□ 

B. 

□ 

C. 

□ 

D. 

□ 

E. 


javax.ejb.AccessLocalException 
javax•ejb.Obj ectNotFoundException 
java.rmi.NoSuchObjectException 
java. rmi. StiabNotFoundException 
javax • ejb. NoSuchEntityException 
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coffee cram mock exam 


Given the container-managed unidirectional relationship: 

Foo (0-1) —> Bar (0-1) 

And the object relations: 

fl -> bl 
f2 -> b2 


What will be true after the following code runs? (Choose all that apply.) 


f2.setBar(f1.getBar()); 

□ A. fl.getBar() == null 

□ B. b2 . getFoo () == null 

□ C. bl.getBar () == null 

口 E. none of the above 


5 


If an entity bean A has been removed from a relationship with bean B, in 
which case(s) will bean A’s accessor method for bean B return a non-null 
value? (Choose all that apply.) 


□ 

A. 

one-to-one 

□ 

B. 

many-to-one 

□ 

C. 

many-to-many 

□ 

D. 

all of the above 

□ 

E. 

none of the above 


Which deployment descriptor element’s value (s) must be a type of collection? 
(Choose all that apply.) 

Q A. <ejb-name> 

Q B. <cmr-field> 

口 C. <cmr-field-type> 

Q D. <ejb-relation> 
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Which deployment descriptor element(s) must have exactly two declarations 
of another deployment descriptor element? (Choose all that apply.) 

Q A. <ejb-name> 

Q B. <cmr-field> 

Q C. <cmr-field-type> 

Q D. <ejb-relation> 

口 E. <ejb-relationship - role> 


Which set(s) of elements are mandatory within an ejb-relationship-role 
element? (Choose all that apply.) 

口 A. <cmr-field> f <multipiicity> 

Q B. <cmr-field>, <relationship-role-source> 

Q C. <multiplicity >, <relationship-role-name> 

Q D. <multiplicity >, <relationship-role-source> 

口 E. <relationship-role-name >, <relationship-role-source> 


Which are valid values for a cmr-field-type element? (Choose all that apply.) 
口 A. String 
口 B. Integer 

□ C. java.util.Set 

□ D. java.util.List 

□ E. java.util.Collection 


Which set(s) of elements are mandatory within an ejb-relation element? 


Q A. <ejb-relation-name > r <ejb-relationship-role> 

Q B. <ejb-relationship-role > r <ejb-relationship-role> 

口 C. 〈 description 〉， <ejb-relation-name > r 
<ejb-relationship-role> 

Q D. <ejb-relation-name >, <ejb-relationship-role>, 

<ejb-relationship-role> 


you are here ► 427 






coffee cram mock exam 


Given CMP beans CustomerBean, OrderBean, and LineltemsBean with the 
following relationships: 

CustomerBean (1) < — > OrderBean (n) 

OrderBean (1) < — > LineltemsBean (n) 

and the following EJB QL query: 

SELECT DISTINCT OBJECT (c) 

FROM Customer c, IN (c.Order) o, IN (o.lineltems) li 

WHERE li .product 一 type = 'refrigerator ' 

Which of the following properly describes the result of the query? (Choose all 
that apply.) 

Q A. The query is invalid. 

口 B. All orders that include a line item that refers to a refrigerator. 

口 C. All line items that refer to a refrigerator. 

Q D. All customers that have order (s) that refer to a refrigerator. 


Given CMP beans CustomerBean, OrderBean, and LineltemsBean with the 
following relationships: 

CustomerBean (1) < — > OrderBean (n) 

OrderBean (1) < — > LineltemsBean (n) 

Which will return all orders that have line items? (Choose all that apply.) 

□ A. SELECT DISTINCT o 

FROM Order o, IN (o.lineltems) li 

□ B. SELECT DISTINCT OBJECT(o) 

FROM Order o, IN (o.lineltems) li 

□ C. SELECT OBJECT(o) 

FROM Order o 
WHERE o.lineltems - 0 

□ D. SELECT OBJECT(o) 

FROM Order o 
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What’s true about EJB QL path expressions? (Choose all that apply.) 

口 A. In a path expression the (•) is considered the navigation operator. 

口 B. Path expressions can terminate with either cmr-field or cmp-field. 

口 C. A path expression that ends in a cmr-fieId cannot be further 
composed. 

Q D. A path expression can end with a single value or a collection value. 


What’s true about EJB QL queries? (Choose all that apply.) 

Q A. Of the three clause types, SELECT, FROM, and WHERE, only the 
SELECT clause is required. 

Q B. The SELECT clause designates query domain. 

口 C. The WHERE clause determines the types of objects to be selected. 

口 D. An EJB QL query may have parameters. 

What’s true about EJB QL WHERE clauses? (Choose all that apply.) 

Q A. Identification variables used in a WHERE clause can be defined only in 
the FROM clause. 

Q B. Identification variables can represent a single value or a collection. 

口 C. The number of input parameters must equal the number of 
parameters for the finder or selector method. 

Q D. Input clauses can only be used in WHERE clauses. 

Given the EJB QL expression: 

p. discount BETWEEN 10 AND 15 


Which expression is equivalent? 


□ 

A. p.discount > 

10 

□ 

B. p.discount >= 

=10 

□ 

C. p.discount > 

10 

□ 

D. p.discount >= 

=10 


p.discount < 15 
)p.discount < 15 


10 and p.discount <= 15 






coffee cram mock exam 
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What’s true about EJB QL, IN expressions? (Choose all that apply.) 

Q A. The single_valued_path—expression must have a String value. 
Q B. The NOT logical operator can be used in an IN expression. 

Q C. The string literal list can be empty. 

Q D. The following expression is legal: o. country IN (“UK” ， “US ”） 


18 


Given the EJB QL expression: 


product.code LIKE ‘F_s’ 


Which value(s) would result in a true comparison? (Choose all that apply.) 

□ A. Fs 

□ B. FIs 

□ C. FXs 

□ D. F37s 

□ E. Fits 
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What’s true for an entity bean provider using container-managed persistence 
to create persistent relationships? (Choose all that apply.) 

M A. A local interface is required for such a bean to have a bidirectional 
relationship with another entity bean. 

Q B. Such a bean can have relationships with only session beans. 


□ 

□ 


C. 

D. 


Relationships can be only one-to-one or one-to-many. 
A getter method return type can be java.util.List . -相认 


st U CoWtt^ or 


Set 


What’s true for an entity bean provider using container-managed persistence 
to create persistent relationships? (Choose all that apply.) 


□ A. 

□ B. 

□ C. 

aT d. 


A remote interface is required for such a bean to have a bidirectional 一 must be lodal 
relationship with another entity bean. 

Such a bean can have relationships with only message-driven beans. 

A get method return type can use java.util.Map. - only Collcdtio^ o\r Srt 
Relationships can be one-to-one, one-to-many, or many-to-many. 


When a remote client invokes a method on an entity bean using container- 
managed persistence, and that bean has already been removed, what 
exception will be thrown? 


□ A. 

□ B. 
^ C. 

□ D. 

□ E. 


javax. e jb. AccessLocalException 
javax. ejb. Ob j ectNotFoundException 
j ava. rmi. NoSuchOb j ec tException 
java, rmi. StubNotFoundException 
j avax. ejb. NoSuchEn ti tyExcep tion 


( s 〜 •⑽ 
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Given the container-managed unidirectional relationship: 
Foo (0-1) —> Bar (0-1) 


I ⑽ 


And the object relations: 

fl -> bl 
f2 -> b2 

What will be true after the following code runs? (Choose all that apply.) 


f2.setBar(fl.getBar()); 

The srtBavO method “breaks 

^ A. f1.getBar()== 


bo-th of okjed-t 

null 

OY\C 

2^ B. b2.getFoo()== 

null 


□ C. bl. getFoo ()== 

Q D. none of the above 

null 



If an entity bean A has been removed from a relationship with bean B, in 
which case(s) will bean A’s accessor method for bean B return a non-null 
value? (Choose all that apply.) 


口 A. one-to-one 
口 B. many-to-one 


C. many-to-many 


Q D. all of the above 
口 E. none of the above 


Which deployment descriptor element’s value (s) must be a type of collection? 
(Choose all that apply.) 

口 A. <ejb-name> 

Q B. <cmr-field> 

a^c. <cmr-field-type> - Collcd*tio»r> o\r Set* 

Q D. <ejb-relation> 


•肌) 
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Which deployment descriptor element(s) must have exactly two declarations 
of another deployment descriptor element? (Choose all that apply.) 


□ 

□ 

□ 

ar 

□ 


A. <ejb-name> 

B. <cmr-field> 

C. <cmr-field-type> ^ ^ W 

D. <ejb-relation> t 

E. <ejb-relationship-role> 




(s ? e6 ： 柯肩 ) 


Which set(s) of elements are mandatory within an ejb-relationship-role 
element? (Choose all that apply.) 


(s_: ㈣) 


口 A. <cmr-field>, <multiplicity> 

Q B. <cmr-field>, <relationship- role - source> 

□ C. <multipiicity>, <relationship-role-name> ^ ,. 七 ^ and 

^ D. <multipiicity>, <relationship-role-source> ave 代匕七以 
口 E. <relationship-role-name> r <relationship-role-source> 


Which are valid values for a cmr-field-type element? (Choose all that apply.) 


(s ? c6 ： W 


□ 

□ 


aT 


□ 


A. String 

B. Integer 

C. java.util.Set 

D. java.util.List 

E. java.util.Collection 


lo6dl 

I CoWc^o^ or 
he \o6a\ 


Which set(s) of elements are mandatory within an ejb-relation element? 


(s ? e6 ： ¥>1 肩 ) 


□ 

□ 


A. <ejb-relation-name >, <ejb-relationship-role> 

B. <ejb-relationship-role >, <ejb-relationship-role> 

C. 〈 description 〉， <ejb-relation-name>, 

<ejb-relationship-role> 


ybta have b*Jo 
fa\rthcv-s 


Q D. <ejb-relation-name >, <ejb-relationship-role > r 
<ejb-relationship-role> 
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Given CMP beans CustomerBean, OrderBean, and LineltemsBean with the 
following relationships: 

CustomerBean (1) < — > OrderBean (n) 

OrderBean (1) < — > LineltemsBean (n) 


(s 〜 


and the following EJB QL query: 

SELECT DISTINCT OBJECT (c) 

FROM Customer c, IN (c.Order) o, IN (o.lineltems) li 

WHERE li .product type = 'refrigerator ' 


Which of the following properly describes the result of the query? (Choose all 
that apply.) 

Q A. The query is invalid. 

口 B. All orders that include a line item that refers to a refrigerator. 

口 C. All line items that refer to a refrigerator. 




D. All customers that have order (s) that refer to a refrigerator. 


Tk StUtCT &说 

1st veW 
objects. 


n 


Given CMP beans CustomerBean, OrderBean, and LineltemsBean with the 
following relationships: 

CustomerBean (1) < — > OrderBean (n) 

OrderBean (1) < — > LineltemsBean (n) 




Which will return all orders that have line items? (Choose all that apply.) 

□ A. SELECT DISTINCT o 

FROM Order o, IN (o.lineltems) li 

tST B. SELECT DISTINCT OBJECT(o) 

FROM Order o, IN (o.lineltems) li 

□ C. SELECT OBJECT(o) 

FROM Order o 
WHERE o.lineltems - 0 

^ D. SELECT OBJECT(o) 

FROM Order o 


434 Chapter 7 







entity bean relationships 


What’s true about EJB QL path expressions? (Choose all that apply.) 


A. In a path expression the (•) is considered the navigation operator. 


^ B. Path expressions can terminate with either cmr - field or cmp-field. 

Q C. A path expression that ends in a cmr - field cannot be further 
composed. 

D. A path expression can end with a single value or a collection value. 


What’s true about EJB QL queries? (Choose all that apply.) 

Q A. Of the three clause types, SELECT, FROM, and WHERE, only the 
SELECT clause is required. 

Q B. The SELECT clause designates query domain. 

口 C. The WHERE clause determines the types of objects to be selected. 


4 


D. An EJB QL query may have parameters. 


What’s true about EJB QL WHERE clauses? (Choose all that apply.) 




A. Identification variables used in a WHERE clause can be defined only in 
the FROM clause. 


Q B. Identification variables can represent a single value or a collection. 

口 C. The number of input parameters must equal the number of 
parameters for the finder or selector method. 


A 


D. Input clauses can only be used in WHERE clauses. 


Given the EJB QL expression: 


p .discount BETWEEN 10 


15 


Which expression is equivalent? 

Q A. p.discount > 10 AND p.discount < 15 
Q B. p.discount >= 10 AND p.discount < 15 
□ C. p• discount > 10 and p.discount <= 15 


4, 


D. p.discount >= 10 and p.discount <= 15 


_ 你-似 ) 


( s ? e 6： 训-训 ) 


一 nn - _ 
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18 


What’s true about EJB QL, IN expressions? (Choose all that apply.) 

^ A. The single 一 valued_path 一 expression must have a String value. 


( s ? e 6： Vl ° {-⑽ 


4 


B. The NOT logical operator can be used in an IN expression. 


Q C. The string literal list can be empty. 

Q D. The following expression is legal: o. country IN (“UK”, “US ”） 
Given the EJB QL expression: 


out Jor 

(JovaWc 


product.code LIKE ‘F_s’ 


Which value(s) would result in a true comparison? (Choose all that apply.) 


□ 




A. Fs 

B. FIs 

C. FXs 


□ D. F37s 

□ E. Fits 


TV^c % \s a 

Lldtavd W a 
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8 messcige-drlVen beans 




w 


Getting the Message 



■II 


Wow! Message-driven 
beans are fantastic! I can send a 
message, and then go back to what I 
was doing before, without waiting 
for a reply. That means I have more 
time to read this nifty ''Head 
First Slide Rule” book... 




It’S fun to receive messages. Not as much fun as, say, getting that EBay 


package with the genuine Smurf™ lamp, but fun and efficient nonetheless. Imagine 


if you sent your order to EBay, and you couldn’t leave your house until the package 


was delivered. That’s what it’s like with Session and Entity beans, because there’s all 


calls to a bean’s client interface (home, component, local, Remote, doesn’t matter) are 
synchronous. But with message-driven beans, the client makes a message and sends it 
to a messaging service. Then the client walks away. Later, the messaging service sends 
the Container the message, and the Container give it to a message-driven bean. 


this is a new chapter 
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exam objectives 



10.1 Identify correct and incorrect statements 
or examples about the client view, and 
lifecycle, of a message-driven bean. 


10.2 Identify the interface(s) and methods a 
message-driven bean must implement. 


10.3 Identify the use and behavior of the 

MessageDrivenContext interface methods. 


10.4 From a list, identify the responsibility of the 
Bean Provider, and the responsibility of the 
Container provider, for a message-driven 
bean. 
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You have to know that message-driven beans don’t 
have clients! That means no home interface, no 
component interface, and no issues of local vs. 
Remote. Of course message-driven beans do have a 
caller, but that’s the Container. And we don’t consider 
the Container a client. The Container is the boss, not 
the customer. 

Message-driven beans have a very simply lifecycle — if 
you know how stateless session beans work, you 
know how message-driven beans work. The only 
different is that instead of bringing a bean out of the 
pool to service a client method call, the Container 
brings message-driven beans out of the pool to 
service an incoming JMS message. 

You must know that message-driven beans implement 
two interfaces — javax.ejb.MessageDrivenBean, the 
interface with the Container callbacks (not many!) and 
javax.jms.MessageListener, the interface with a single 
onMessage(Message m) method. For a message- 
driven bean, onMessage() is the only business 
method. 

You have to know that message-driven beans can’t 
call most of the methods in MessageDrivenContext, 
ever. Think about it. If there’s no client, how could 
you get client security info? If there’s no client, which 
means no client view, how could you call getEJBOb- 
ject() or getEJBHome()? You don’t have a home! You 
don’t have an EJBObject(). 

You also have to recognize that if there’s no client, you 
can’t declare any checked exceptions. Who would 
catch them? Also, just as with stateless session beans, 
if you start a transaction in a method (which can only 
mean a BMT bean in onMessage()) you must finish it 
before the method ends. 







message-driven beans 


Imagine this scenario... 

You have to ask someone to do a very important job. 
You have no idea how long it’s going to take them. 
You have to wait right where you are until they finish. 
You can’t do anything else while you’re waiting. 


...please oh please don’t 
take all day on this... I have 
SO many other things I’d 
rather be doing than wait 
here for you to finish... 
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message-driven beans 
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message-driven beans 



Tell him to chill. Well 
get to it...and ifs not 
like he's got anything 
better to do. 


Hey, were at the 
pool, dude. I thought I 
told you never to call me 
here. 


Server 


Client 


before message-driven beans 



Too bad these guys aren't 
message-driven beans 

Method calls, local or remote, are synchronous. 
The caller is stuck waiting until the server returns. 

Message-driven beans (added in EJB 2.0) give 
you asynchronous communication between the 
client (message sender) and the server (message 
receiver). 

In messaging terms, the sender is called the 
message Producer and the receiver is called the 
message Consumer. 

With messaging, the Producer sends a message and 
then goes about his business. He doesn’t have to 
wait for the Consumer to even get the message, let 
alone process it. 

When the Consumer gets a message, he processes 
it. In the meantime, the client can still have a life. 



after message-drivew beans 
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Message-driven bean overview 

Client (Producer) send a message to 
the messaging service. 



(2) Message is delivered to the 
Container. Client is doing other 
client things. 


messaging service 




Message-driven 
Bean Pool 






③ 



messaging service 


Container acknowledges the 
message to the service, and 
pulls a bean out of the pool to 
process the message. 
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④ 


Container invokes the beans 
onMessage() method, with the 
message as the argument. 



Message-driven 
Bean Pool 





If the bean’s transaction in messaging service 
onMessage had rolled back, 
the Container would have told the 
messaging service to put the 
message back on the queue. 


The bean’s transaction commits, 
and the Container sends the bean 
back to the pool. 


陳 t they look a lot like stateless session beans? 


Like stateless session beans, message-driven beans have no 
unique identity to clients (actually, they don’t have clients, 
since the Container isn’t really considered a client to the 
bean), they’re pooled, and they have no individual state 
that affects their business logic. That means one message- 
driven bean (of a particular type) is the same as any other 
bean from the same home. Just like stateless beans. 
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message-driven beans 


Multiple beans of the same 
type can process messages 
concurrently. 



But the container will make sure 
that each bean is thread safe! 



WelcomeBean 



Container 
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message-driven beans 


The lifecycle of message-driven beans 
looks just like stateless session beans 


Message-driven 

bean 

_ bean throws system exception 

does not exist (unchecked, uncaught) 

▲ 


constructor 

setMessageDrivenContext() 

ejbCreate() 


ejbRemove() 





t 


method ready 


onMessage() 






or 


YVO 






dv-ivch 

ohly 0MB- business 
•method— ohMcssajcO. 


public void onMessage(Message msg) { 

// open the message and do something with it 

以？ S ⑽ 
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Message-driven bean class 


package headfirst 

import javax.ejb, 
import javax.jms, 


淡％ 轉 


TWO 




public class WelcomeBean implements MessageDrivenBean, MessageListener 




private MessageDrivenContext context; 




Sy\d 


public void ejbCreate () 


public void ejbRemove() 


you 


/\/lU£T V^avc a ^o-av-5 cjbCvcatcO 


>wo\rb just like sla-tclcss session bcatailed 
-tKc Co^ia'mcv y/a^ls "to \rcdutc tKc fool 


public void setMessageDrivenContext(MessageDrivenContext ctx) 
context -- ctx; 

} do -the 




public void onMessage(Message msg) { 

// process the message 
try { 

if (msg instanceof TextMessage) { 
TextMessage message = (TextMessage) msg 

System.out.println(message.getText()); 


巧％ tr : 心 he 


catch (JMSException ex) 
ex.printStackTrace (); 




上 m 似以 bcW tv.c cash 
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message-driven beans 


Writing a messagc-drivew bean: 
your job as Peaw Provider 


This time, there's no client 
view, so I don't have to 
match anything from the home 
or component interfaces. 

They don’t exist. Just like me. 



《 interface 〉〉 

MessageListener 

onMessagef) 


You put THREE kinds of methods 
in the bean class: 

(l) Bean Law: ejbCreate() method 

Write a single, no-argument ejbCreate() method in the 
bean. It doesn’t match anything or come from any inter¬ 
face. It's there because it MUST be. 


(2) MessageListener implementation: 
onMessage() 

This is your business method. Your only business 
method. 



«interface» 

MessageDrivenBean 

ejbRemove() 

setMessageDrivenContext() 


( 3 ) MessageDrivenBean implementation: 
container callbacks 


Implement both of the methods from the 
MessageDrivenBean interface, which your bean must 
implement in the official Java way (i.e. using the 
‘implements MessageDrivenBean' declaration either in 
your bean class or one of its superclasses) 


■^^rpen your pencil 

Of the three types of methods you 
put in your bean, check off the ones 
the compiler cares about. 


Compiler-checked? 

□ ejbCreate() 

□ onMessage() 

□ ejbRemove() and setMessageDrivenContext() 
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Rules for the message-driven bean class 


(?) The class must implement javax.ejb.MessageDrivenBean and 
javax. ejb. MessageListener. 

public class WelcomeBean implements MessageDrivenBean, MessageListener { 

® The class must be public, must not be final, and must not be abstract. 


③ 


The class must have a public constructor that takes no arguments. (Just like 
the other beans... so the Container can make a new instance.) 


public WelcomeBean() 




fe: 工。瓣(） 


yxo-av^) 


Jfault 6 ⑽士 rudW 
a^d do^t 


④ The class must have a no-arg ejbCreate() method. It must be public, not 
final, not static, with a void return type. 


public void ejbCreate () { } 

rnc 铣 od 

a lvcad7 Wc 70 此 


\y\ V^cvc- 
\s tailed, 7<> u 
■te 此 


⑤ The class must define the onMessage() method from the 

MessageListener interface. It must be public, not final, not static, 
with a void return type, and it takes a single argument of type 
javax.jms.Message. 

public void onMessage(Message msg) { ... } 

The RBAL busies VW | 。少 ㈣ 二 … 


⑥ You must have the ejbRemove() and setMessageDrivenContext() 

methods from the MessageDrivenBean interface, exactly as declared 
in the interface. 


Message-driven 
beans can’t 
declare checked 
exceptions!! 

You , ll learn more about 
exceptions in Chapter 10, but for 
now, just think about it There’s no 
client! So who are you expecting 
to wrap a try/catch around these 
calls? The Container will laugh 
if you try to do this. You MUST 
catch and handle any checked 

exceptions that you get!! 


public void ejbRemove() { } 

public void setMessageDrivenContext(MessageDrivenContext ctx) { 
context = ctx; 


No methods in the class are allowed to throw application exceptions. (And they 
shouldn’t be declaring runtime exceptions either, although it’s technically legal.) 
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Notice something missing from the code? 

We never said what kind of messages weVe listening for ： 
or where they might be coming from. 

You don’t put anything in your code that indicates the JMS destination. 

You can probably guess when that happens... deploy-time. 

But as a Bean Provider, you tell the Deployer whether you’re looking for 
messages from a topic or queue. And for that, we’ll use a new tag in the 
deployment descriptor, just for message-driven beans. At deploy-time, the 
Deployer will bind your bean to a specific Topic or Queue configured as a 
resource in the EJB server. 


<message-driven-destination> 

<destination-type 〉 javax•jms.Topic</destination-type> 
</message-driven-destination> \ , 

⑽沪 士^ a Topic 。以々吹 3 


Complete PP for a message-driven bean 


<enterprise-beans> 

<message-driven> 

<ej b -name>WelcomeNewCus tomer< /e jb - name 〉 

<home>headfirst^NCust^merHome</home> 




<remote>headiif ! st. Cu^tomer</remote> 




<ejb-class>headfirst .WelcomeBean</ejb-class> 
<transaction-type>Container</transaction-type> 
<message-driven-destination> 

<destination-type>javax.jms.Topic</destination-type> 


</message-driven-destination> 
</message-driven> 
</enterprise_beans> 


fl/Vc II look a*t dh optional -tag i 
a -Pew pages) 


m 
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Topics and Queues 


Messaging comes in two flavors: topics 
and queues, although topics come in two 
subflavors — durable subscriptions and non¬ 
durable subscriptions. 

Queues are like FIFO lists (although First- 
In-First-Out order isn’t guaranteed). The 
producer sends a message that’s intended 
for just a single consumer. Once somebody 
processes the message, that’s it. An example 
might be an employee reimbursement 
system, where the employee sends his 
reimbursement request to the messaging 
service, and somebody in accounting will 
process the request. It doesn’t need to go to 
anybody else at that point. If it turns out that 
the next step is to send it for management 
processing, the accounting department 
might send a message to a different 
destination — the ManagerApproval queue. 

Topics use a publish and subscribe model, 
where a producer sends a message, and 
anyone who’s listening as a consumer will 
get a copy of the message. Works just like a 
mailing list. If any one subscriber doesn’t get 
the message, the producer doesn’t care. 

A topic subscriber can request a durable 
subscription if he wants to make sure that 
he sees all messages, including the ones 
that accumulated while he was offline, for 
example. That will almost always be your 
choice, because you’ll want to get all the 
messages. Think about it...a non-durable 
topic subscription would be like you must be 
home at the time your magazine is delivered, 
os you simply won’t see it. 


Enterprise systems tend to 
use either queues or durable 
topic subscriptions. A non¬ 
durable topic subscription 
ni^rthe ^propriate 
sometimes, but if Yn a 
message consumer it's really 
like saying, “I don't care 
mcK about I get 

these messages •” 
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Queue: one to one (point-to-point) 


rm an entity bean 
currently playing the brilliantly 
dashing Thomas Paul, and I have a 
private matter that I want someone 
discreet to take care of right away, 
but I don’t want to wait. I have an 
audition coming up... 




Ov\\y oY\t 

-tWis tasc, a 
yts i\\t 




(•, 


\Y\ 





Topic: one to many (publish/subscribe) 
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tWeiqre^P 

Dumb Questions 


How does JMS fit into all 
this? And if I have a message-driven 
bean, where do I get the messaging 
service? 

A- 

JMS 1.02 is the Java Messaging 
Service API that's required by EJB 2.0. 
That means your EJB container must 
have some kind of messaging service 
included, although many vendors 
can work with multiple messaging 
services as long as those services 
support the JMS API. 

The JMS API works much like JDBC — 
you have a driver that knows how 
to take your standard JMS API calls, 
and translate them into something 
the underlying messaging system 
understands. 


Can I get messages from non- 
JMS messaging services? 

A- 

^\ m Not right now, in EJB 2.0, but 
they (the infamous J2EE team) hope 
to add that capability... some day. 


Why doesn’t the 
MessageDrivenBean just extend 
the MessageListener interface? 
That way you wouldn’t have to 
implement both interfaces. 


A ： 


See your previous question. 


The J2EE team didn’t want to lock 


all message-driven beans into being 
JMS listeners. One day, there might be 
many kinds of listener interfaces for 
different messaging types. 


Are messages guaranteed to 
come in order? Will I always get the 
first one first? 


A ： 


No!! You better not depend on 
it or Bad Things Might Happen. For 
example, you might get the "Cancel 
the Order” message before you get 
the "Place the Order” message. Design 
your system and code your bean on 
the assumption that message order is 
not strictly guaranteed. 


If it's a topic, does that mean 
all beans in a particular subscriber 
pool will get the message? 


A- 

No! Remember,one bean can 
stand in for all the other beans.The 


Container will deliver the message to 
just ONE bean in the pool. Unless... no 
never mind. 


Unless what? Tell me! 

OK, OK. But this isn't on the 
exam, so relax. Let’s say your server is 
running as a clustered configuration, 
where you could have multiple 
instances of your server running. In 
that case, there is no guarantee about 
how the Container will represent itself 
to the messaging service. 

The question becomes, does the 
messaging service see the whole 
cluster as ONE version of your 
application, no matter how many 
JVMs its running on, or does the 
messaging service see each cluster 
(with its own duplicated pool for each 
bean type) as a separate listener? 
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Only ONE bean per pool gets 
a copy of a topic message 


If you have, say, the WelcomeBean subscribed to 
the NewCustomer topic, when a new message is 
published to that topic, the Container will choose 
only one bean from the WelcomeBean pool to get 
the message. Remember, the Container keeps a 
separate pool of beans for each home (and every 
deployed bean type gets its own home). The 
Container doesn’t put all message-driven beans 
into one pool, even if they’re subscribed to the 
same topics. 

But if there are multiple bean types subscribed 
to that topic, one bean from each of those pools 
will also get the message. In this picture, both 
the WelcomeBean and the NewSalesBean are 
subscribers to the NewCustomer topic, so the 
Container selects one bean from each pool to get 
the message. 





NewCustomer 
Topic message 


K 工⑼ T 

叫 bea “ 如 ? ool! 


NewCustomer 
Topic subscriber 



NewCustomer 
Topic subscriber 
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JMS queue 


With a queue, only one bean 
gets the message. Period. 


If you have a queue for messages requesting that 
a new customer be processed, only one bean 
from the pool associated with that queue will get 
the message. That’s it. 

Oh, and don’t even think about asking what 
happens if you have more than one bean type 
(pool) associated with that queue. 

But if you persist, we’ll tell you that JMS doesn’t 
define what happens when there is more than 
one consumer for a particular queue. That 
means there’s no way to know how the messages 
might be distributed among the different queue 
consumers. Maybe the messaging service will just 
pick one at random. But maybe it won’t. Maybe 
it’ll just pick the first one in a properties file and 
send everything there. So, just don’t do it. 


?oo\. 


ProcessCustomer 
queue listener 



ProcessCustomer 
queue message 


JMS 
Messaging 
Service 




J 




454 


Chapter 8 







message-driven beans 


McssagcPrivcwCowtcxt 

The server makes message-driven beans virtually 
the same way in which it makes stateless session 
beans. 

1. Call the bean’s constructor (must be no-arg). 

2. Call the bean’s context setter. 

3. Call the beans ejbCreate() method. 

In fact, the first two steps are the same for all 
bean types. The context setter always comes 
immediately after the bean’s constructor, and at 
some point before ejbCreate(). (And of course 
an entity bean might never get an ejbCreate() 
call, if there aren’t any clients trying to insert new 
entities into the database.) 

So, what can a message-driven bean do with its 
context? We think it’s time for you to figure that 
out. We can guarantee there will be questions 
on the exam related to what a message-driven 
bean can and cannot do with its context. In fact, 
you’ll find these questions scattered throughout 
the objectives, not just in the message-driven 
bean objectives (10.1 - 10.4). Questions from the 
transactions, exceptions, and security objectives 
might involve a message-driven bean and its 
context. 

This is just our way of saying., do the damn exercise! 

You don’t want to have to memorize this stuff, but 
if you just spend a few moments thinking about 
it, you’ll figure it out. 

The answers are on the next page, though, so 
don’t turn until you’re done. 



Think about which methods a message-driven bean 
could call on its context. 

From the list of methods in EJBContext, cross 
out those methods that do not make sense for a 
message-driven bean (and by “do not make sense” 
we mean “will cause a horrible runtime exception 
with devastating and potentially career-ending 
consequences"). 

Oh, and be prepared to defend your answers. 
Imagine us sitting right behind you, scarily, 
demanding justification for your choices. 


《 interface 》 

EJBContext 


getCallerPrincipal() 

getEJBHome() 

isCallerlnRole(String s) 

getRollbackOnly() 

getEJBLocalHome() 

getUserTransaction() 

setRollbackOnlyO 


▲ 


《 interface 〉〉 

MessageDriven Context 

II this interface adds no 
//new methods 
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McssagcPrivcwCowtext 


《 interface 》 

EJBContext 


geiCallerPrincipal() 

getEJBHome() 

isCallerinRoie(String s) 

getRollbackOnly() 

getEJBLocalHome() 

getUserTransaction() 

setRollbackOnly() 


《 interface 》 

MessageDrivenContext 

//this interface adds no 
//new methods 


: a«cvPv^a\0 and 
t\\t^ 


sc6vav 
t\\t 


My life is sad. I have 
no home, I have no callers... 
(except the stupid Container, 
and that*s like saying the only 
friends you have are your 
parents). Oh well, at least 
I get a pool. 



It’S simple. Message-driven 
beans don't Kave clients. That 
means ikey don’t have a client 
VIEW, so there's no toie 
interface. 

And since here's no client, 
there's no client Securiiy 
information. 

So, you can't call the two 
mediods for getting ihe Wie 
(since you HAVE no Home), or 
ilie two methods for getting 
info about 也 e caller's securiiy. 



You keep saying that message-driven 
beans don't have clients. But SOMEBODY has 
to call the bean’s methods, right? They don’t 
call themselves... 


A ： 


Technically, yes, the bean’s methods are 


called. But we don’t consider the Container to 


be a client. It’s the boss, not the customer. So, in 
the Java sense, the Container is the bean’s caller, 
but not a client. And as for getting security info, 
if the bean doesn't trust its own Container, you 
have waaaay bigger problems. We’re talking one 
seriously paranoid bean. 
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What if something goes wrowg? 


message-driven beans 


Everything was going so well... 



When suddenly … 



Houston, we have 
a problem. Looks like we 
better put that message back 
on the queue so somebody else 
can deal with it. Poor bean 
must have hit a runtime 
exception... 




JMS 
Messaging 
Service 
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Message acknowledgement 

You don’t want messages getting lost. If you have a crucial message 
on the queue, and the one bean who gets it can’t commit — or 
worse, throws an exception and dies — what happens to your critical 
message? 

That’s the point of acknowledgement. The Container tells the 
messaging service (not the original producer) that the message was 
delivered and everything is fine. 

But if later, while the consumer (the message-driven bean) is 
processing the message, a Bad Thing happens, the Container can 
tell the messaging service to put the message back in the queue. 

How does the Container really know that something went wrong? 
Two ways, and it’s your choice as a Bean Provider. 


① The transaction status 

Message acknowledgement is tied to whether the transaction 
commits or rolls back. If the transaction rolls back, the message 
goes back on the queue. You get this behavior for beans that use 
container-managed transaction demarcation (we’ll cover transactions 
in the next chapter). 

OR 

② The method completion 

Message acknowledgement is tied to whether the method 
completes successfully. If the method throws a runtime 
exception, the message goes back on the queue. You get 
this behavior for beans that use bean-managed transaction 
demarcation. 
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That》all well and good, but let's go back and 
see how our earlier scenario ended... 





Bean A, dead 


Here's a message 
from the queue. I*m sure 
you II do better than 
that LAST guy... 

D" 

Q 


JMS 
Messaging 
Service 




Oh, definitely. 
There's nothing I 
can't handle. 



Bean B, alive 





Q 


Bean C, alive 



Bean C, dead 


Um, do you think 
maybe there's something 
wrong with the 
message? 




JMS 
Messaging 
Service 
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message acknowledgement 


Thiwk about it. 

If you want your message acknowledgement tied to the status of the transaction, use 
container-managed transactions (CMT). Most of the time, this will be your choice. 

But if you want to decouple message-acknowledgement from the status of your 
transaction, your only choice is to use bean-managed transaction demarcation 
(BMT). With BMT, the Container looks only at whether your method completes. 
Method completes? Fine, the message acknowledgement stands. Runtime 
exception? Message goes back in the queue. 

But what if you have a scenario where the bean can never commit, because of 
something inherently bad about the message? With CMT, that message will keep 
coming and coming and coming and... but not forever. Most messaging services let 
you configure how many times a particular message is resent before the service says, 
“This message looks like poison; let’s send it to a Special Place (like a Bad Message 
queue) where it can’t harm anyone”. You really need to watch out for this, because 
there’s nothing in the spec to help. You’re reliant on your server vendor! 

There is another possibility, though. With BMT, you could write your method in 
such a way that you rollback the method, but still finish the method. That way, the 
Container just goes whistling on its merry way thinking everything was fine. It has no 
idea that things went badly. In this scenario, you’d catch whatever exception comes 
up, rollback the transaction yourself (again, you’ll learn how to do that very soon), 
and then end the method looking successful (at least to the Container). 



O^ tbe potl) 


Setting the acknowledgement mode 

If you DO use BMT, you have two choices for how the Container sends an 
acknowledgement to the messaging service. The choices are: 

〈 acknowledge-mode>Auto-acknowledge</acknowledge-mode> 

OR 

<acknowledge-mode>Dups-ok-acknowledge</acknowledge-mode> 

This doesn’t change the Container’s behavior of whether it decides to do the 
acknowledgement — for a BMT bean it’s always based on whether the method 
completes. The acknowledge mode is simply a way to tweak how the Container 
sends the acknowledgement. 

With Dups-ok-acknowledge, you’re telling the Container that you don’t mind if it’s 
kind of slow with the acknowledgement to the message service... that you don’t mind 
if you get duplicate messages (“dups-ok”）. This lets the Container take whatever 
time it wants to do the acknowledgement, and it might make the server more 
efficient, but at the risk of duplicate messages because the poor messaging service 
didn’t get an acknowledgement quickly enough. 
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① 


Fill-in the blanks with the code that must be inserted for 
the bean to be a legal message-driven bean class. 


package headfirst; 


import javax.ejb.*; 
import javax.jms.*; 


public class FooListenerBean 


private MessageDrivenContext context; 


public void _ 

public void _ 

public void setMessageDrivenContext(MessageDrivenContext ctx) { 
context = ctx; 

} 

public void _ 



List two things a stateful session bean can call on its 
SessionContext, that a message-driven bean can never 
call on its MessageDrivenContext. 
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① 


Fill-in the blanks with the code that must be inserted for 
the bean to be a legal message-driven bean class. 


package headfirst; 


import javax.ejb.*; 
import javax.jms.*; 


public class FooListenerBean /^essayLisje^v 


private MessageDrivenContext context; 


cjbCvcaicO { } 


public void 



public void 


public void setMessageDrivenContext(MessageDrivenContext ctx) { 
context = ctx; 

} 

public void Q^gssayC/^essay msg) { }_ 


List two things a stateful session bean can call on its 
SessionContext, that a message-driven bean can never 
call on its MessageDrivenContext. 


Cd\\ isCallcv|hRolcO ( 七 Vive’s ⑽ 



462 


Chapter 8 








message-driven beans 





Utoc^ Sxom 


What’s true about message-driven beans? (Choose all that apply.) 

口 A. A message-driven bean has a home interface but no component 
interface. 

口 B. A client never knows a message-driven bean’s identity. 

口 C. A client sees a message-driven bean as aJavaMail message consumer. 
[I D. The lifetime of a message-driven bean is controlled by the container. 

Which interfaces must be implemented in a message-driven bean class or in 
one of its superclasses? (Choose all that apply.) 

Q A. javax. jms .Message 

□ B. javax. jms .MessageListener 

□ C. javax. jms .MessageConsumer 
Q D. j avax. e jb. MessageDrivenBean 

□ E. javax.ejb.MessageDrivenContext 


Which list properly sequences the methods called in the lifecycle of a message- 
driven bean? (Choose all that apply.) 

□A. ejbCreate (), newlnstance (), setMessageDrivenContext (), 
onMessage() 

□ B. onMessage (), newlnstance (), ejbCreate(), 

setMessageDrivenContext() 

□ C. newlnstance () , setMessageDrivenContext。，ejbCreate (), 

onMessage() 

□ D. newlnstance (), ejbCreate (), setMessageDrivenContext (), 

onMessage() 

□ E. ejbCreate (), setMessageDrivenContext (), newlnstance (), 

onMessage() 
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Which are valid signature (s) for methods in a message-driven bean? (Choose 
all that apply.) 

□ A. public void onMessage() 

□ B. public void ejbCreate() 

□ C. public static void onMessage() 

□ D. public void ejbCreate (javax. jms .Message m) 

□ E. public void onMessage (javax. jms .Message m) 

Q F. public void onMessage (javax. jms .Message m) throws 

j ava. rmi. Remo teExcept ion 


When is a message-driven bean able to access java:comp/env via JNDI? 

□ A. ejbCreate () 

□ B. ejbRemove () 

□ C. setMessageDrivenContext() 

Q D. None of the above 


6 


Which message-driven bean methods take an argument? (Choose all that 
apply.) 


□ A. ejbCreate () 

□ B. ejbRemove () 

□ C. onMessage () 

□ D. setMessageDrivenContext() 


7 


When is a message-driven bean able to access other enterprise beans? 

□ A. ejbCreate () 

□ B. ejbRemove () 

□ C. onMessage () 

□ D. setMessageDrivenContext() 

口 E. None of the above 
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What’s true about Container support for message-driven beans? (Choose all 
that apply.) 

Q A. The Container must support the deployment of a message-driven bean 
as the consumer of aJavaMail queue. 

Q B. The Container is NOT required to support transaction scoping for 
message-driven beans. 

口 C. The Container guarantees first-in, first delivered message processing. 
口 D. The Container must ensure that the bean instances are non-reentrant. 

When is a message-driven bean with BMT demarcation able to access resource 
managers? 

□ A. ejbCreate () 

□ B. ejbRemove () 

□ C. onMessage () 

□ D. setMessageDrivenContext() 

口 E. None of the above 


What’s true about message acknowledgment for message-driven beans? 

(Choose all that apply.) 

口 A. Message acknowledgement modes cannot be defined declaratively. 

Q B. The JMS API should be used for message acknowledgment. 

口 C. For BMT beans, the Container uses the acknowledge-mode deployment 
descriptor element. 

Q D. For CMT beans, the Container uses the acknowledge-mode 
deployment descriptor element. 


What’s true about the deployment descriptor for message-driven beans? 

(Choose all that apply.) 

Q A. The bean provider must guarantee that the bean is associated with a 
specific queue or topic. 

口 B. The deployment descriptor can indicate whether a bean is intended for 
a topic or a queue. 

口 C. It can indicate whether a Queue type bean should support durable 
subscription or not. 

口 D. It is appropriate to associate multiple beans with the same JMS queue. 
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What’s true about message-driven beans? (Choose all that apply.) 

Q A. A message-driven bean has a home interface but no component 


(s_: 




interface. 


MDBs have UO diehi vi 
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B. A client never knows a message-driven bean’s identity. 

Q C. A client sees a message-driven bean as aJavaMail message consumer. 

^ D. The lifetime of a message-driven bean is controlled by the container. 

Which interfaces must be implemented in a message-driven bean class or in 
one of its superclasses? (Choose all that apply.) 

Q A. javax. jms .Message 

^ B. javax. jms .MessageListener - *t^ ,s ,s the o^McssajcO w\c*thod is dc-f'mcd 

□ C. j avax. jms . MessageConsumer 
^ D. javax.ejb.MessageDrivenBean 

□ E. javax.ejb.MessageDrivenContext 


view 
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Which list properly sequences the methods called in the lifecycle of a message- 
driven bean? (Choose all that apply.) 

□A. ejbCreate (), newlnstance(), setMessageDrivenContext (), 
onMessage() 


(和训 ) 


□ B. onMessage (), newlnstance (), ejbCreate(), 
setMessageDrivenContext() 

^ C. newlnstance () r setMessageDrivenContext () r ejbCreate(), 
onMessage() 


□ D. newlnstance (), ejbCreate () f setMessageDrivenContext (), 

onMessage() 

□ E. ejbCreate(), setMessageDrivenContext (), newlnstance (), 

onMessage() 
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Which are valid signature (s) for methods in a message-driven bean? 
all that apply.) 


(Choose 




□ 


A. public void onMessage () 

B. public void ejbCreate() 


□ C. public static void onMessage() 

□ D. public void ejbCreate(javax.jms.Message m) 

^ E. public void onMessage (javax. jms .Message m) 

Q F. public void onMessage (javax. jms .Message m) throws 
j ava. rmi. RemoteException ^ ^ 缸 | a 代 a 

When is a message-driven bean able to access java:comp/env via JNDI? 

^ A. ejbCreate () 

^ B. ejbRemove () 

^ C. setMessageDrivenContext() 

口 D. None of the above 
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Which message-driven bean methods take an argument? (Choose all that 
apply.) 

□ A. ejbCreate () 

□ B. ejbRemove () 

C. onMessage () - a 

^ D. setMessageDrivenContext () - iskcs a 亡 。 htext 




7 


When is a message-driven bean able to access other enterprise beans? 


□ 

□ 




A. ejbCreate () 

B. ejbRemove () 

C. onMessage () 




a 




□ D. setMessageDrivenContext() 

口 E. None of the above 


( s ? 私:兑 0 ) 
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What’s true about Container support for message-driven beans? (Choose all 
that apply.) 


( s ? e 6： 如- 似) 


Q A. The Container must support the deployment of a message-driven bean 
as the consumer of aJavaMail queue. 

Q B. The Container is NOT required to support transaction scoping for 
message-driven beans. 

Q C. The Container guarantees first-in, first delivered message processing. 
^ D. The Container must ensure that the bean instances are non-reentrant. 

When is a message-driven bean with BMT demarcation able to access resource 
managers? 




□A. ejbCreate() 

□ B. e jbRemove () 

^ q onMessage() 一 4 ⑶ is S tv*air\sad.*tiojr\ 

□ D. setMessageDrivenContext() 

口 E. None of the above 
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What’s true about message acknowledgment for message-driven beans? 
(Choose all that apply.) 


(s_ H) 


Q A. Message acknowledgement modes cannot be defined declaratively. 

Q B. The JMS API should be used for message acknowledgment. 

C. For BMT beans, the Container uses the acknowledge-mode deployment 

descriptor element. be - o\r 


Q D. For CMT beans, the Container uses the acknowledge-mode 
deployment descriptor element. 


Pups-ok-a^khowlcdijc 


What’s true about the deployment descriptor for message-driven beans? 
(Choose all that apply.) 




: 


□ A. The bean provider must guarantee that the bean is associated with a 一 $ ^ 

specific queue or topic. 

^ B. The deployment descriptor can indicate whether a bean is intended for 
a topic or a queue. 

Q C. It can indicate whether a Queue type bean should support durable - durable subsdjriftiohs arc 
subscription or not. jus 七 

口 D. It is appropriate to associate multiple beans with the same JMS queue. 
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♦ The Atomic Age 


It was a long 


transaction, but she finally 
committed. She had plenty 
of time to rollback, but I 


just kept catching all the 
exceptions, so it all worked 
‘ out in the end. I 


Transactions protect you. With transactions, you can take a risk. You can try 
something BIG, knowing that if anything goes wrong along the way, you can just pretend 
the whole thing didn’t happen. Everything goes back to the way it was before. The idea is 
simple — you either commit to everything in the transaction, or you rollback, so that nobody 
sees what you were trying (but failed) to do. Transactions in EJB are a thing of beauty — 


you can deploy a bean with customized transaction behavior without touching the bean’s 
source code! But you can write transaction code, if you need to, so we’ll learn that too. 


this is a new chapter 
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exam objectives 




S^tctfvzi^c ^Inaadoctcoa^ 

Ct ne<xilcp 


11.1 Identify correct and incorrect 
statements or examples about 
EJB transactions, including bean- 
managed transaction demarcation, 
and container-managed transaction 
demarcation. 

11.2 Identify correct and incorrect 
statements about the Application 
Assembler’s responsibilities, including 
the use of deployment descriptor 
elements related to transactions, and 
the identification of the methods of 

a particular bean type for which a 
transaction attribute must be specified. 

11-3 Given a list of transaction behaviors, 
match them with the appropriate 
transaction attribute. 

11.4 Given a list of responsibilities, identify 
those which are the container’s with 
respect to transactions, including 
the handling of getRollbackOnly, 
setRollbackOnly, getUserTransaction, 
SessionSynchronization callbacks, for 
both container and bean-managed 
transaction demarcation. 

(Note: we cover the part of 11.4 that 
deals with SessionSynchronization in 
the Session Bean chapter.) 
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You need to know the rules, and implications of, bean- 
managed (BMT) vs. container-managed (CMT) transac¬ 
tion demarcation. For example, you must know that both 
message-driven and session beans can use CMT or 
BMT but entity beans can use only CMT. And message- 
driven beans and stateless session beans using BMT 
must end the transaction before the end of the method, 
but stateful session beans are allowed to keep a transac¬ 
tion open across multiple method invocations from a cli¬ 
ent. You need to know that propagation of transactions in 
BMT is a one-way street: a BMT transaction can propa¬ 
gate out with a bean’s method calls (i.e. be used by the 
called method), but an existing transaction context can 
never be propagated into a BMT bean. In other words, a 
BMT bean will run only in transactions the bean itself has 
started. 

You must be very clear about the effects of transaction 
attributes for CMT. For example, you must understand 
that message-driven beans can use only two of the six 
attributes (NotSupported and Required), because the 
others don’t make sense for a message-driven bean (no 
calling transaction can ever be propagated into a mes¬ 
sage-driven bean because it is only the container that in¬ 
vokes the bean’s onMessage() method. You also have to 
know the methods of each bean type (session, entity, or 
message-driven) for which transaction attributes must be 
specified. For example, an entity bean’s create() method 
is transactional, but a session bean’s create。method 
runs in “an unspecified transaction context.” You must be 
able to specify transaction attributes in the deployment 
descriptor. 

Finally, you need to know what your bean can count on 
from the container when it comes to transactions. For 
example, you must know that if you invoke getRollback- 
Only on a bean’s context, the container must not commit 






EJB transactions 



An EJB transaction is an atomic unit of work. 


A transaction means you’ve wrapped some work (statements, method calls, 
whole methods, access to a database, etc.) into a single unit in such a way 
that either everything succeeds, or everything reverts to its previous state. 


In other words，you either commit or rollback the whole atomic unit. 
Either it all works，or we just forget the whole thing ever happened. 



Shopping cart checkout: 
a quintessential EJB transaction example. 

Imagine you have an online shopping cart system. When it comes time 
to checkout, what needs to happen? At the very least: 


■ 


■ 


■ 


Have user confirm order 
Validate and debit user’s credit card 
Remove purchased items from inventory 
Create and submit a shipping order 




You don’t want to debit the inventory if the credit card isn’t valid. And 
you don’t want to submit a shipping order if the items aren’t yet in stock. 
And you don’t want any of it to happen if the user doesn’t confirm the 
order! If any of these things go wrong, you want your transaction to end 
with a rollback, rather than a commit. Think of the horror you’d go 
through if you couldn’t do a transaction rollback. Imagine that you went 
through the first three out of the four steps only to find the user doesn’t 
confirm the order. You would have to go back and add money to the 
user’s credit card, cancel the order, and put the items back in inventory. 



You don’t need to know about JTS ， XA, or any other 
transaction APIs except javax.transaction.UserTransaction. 


You won’t be tested on any of the lower-level transaction API details. For 
example, you don’t need to know anything about HOW the server/container 
communicates with a transactional resource such as a database. And although EJB 
supports distributed transactions, you won’t be asked about how it works. We know it’s 
depressing that you won’t get to show off your two-phase commit protocol prowess. 
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the ACID test 



The ACIP test 

Is your transaction safe? 

Five out of five experts (plus pretty much the entire rest 
of the industry) agree on four characteristics of a good, 
safe transaction. (This is not just an EJB thing, by the 
way — the ACID test goes back long before Java was 
a gleam in Gosling’s eye.) To put your transactions 
through the ACID test, make sure the transaction is: 


Ato 


mic 

Either it all works, or it all fails (and rolls back) 


A transaction isn’t atomic if it’s possible for some of it to 
commit while other parts don’t. 


Consistent 

Whether it works (commits) or fails (rolls back), the 
data should stay consistent with the business logic reality. 
You’d have real trouble if, say, you could take items out 
of inventory without actually submitting an order. You’d 
end up with items that exist in the real inventory (i.e. in 
a warehouse somewhere), but that don’t show up in 
anybody’s computer records. 


Isolated 

Let’s say you have two different transactions running, 
potentially hitting the same database. You don’t want the 
effect of one transaction to corrupt the state of another 
transaction. In other words, the transactions should be 
protected ( isolated) from one another. Isolation is very similar 
to thread synchronization ― you don’t want one transaction 
reading some data (with the intention of acting on it) if that 
data is smack in the middle of another transaction that hasn’t 
finished committing its own changes to the data. 

Durable 

Once a transaction commits, the changes made by that 
transaction must become permanent! Even if the server goes 
down, it must come back up and finish what it started to commit. 
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EJB transactions 




Off Ue pml, 


Pistributcd trawsactiows: two-phase commit 

Most EJB containers support distributed transactions through a two-phase 
commit protocol. If you’re a transaction manager (like aJ2EE server), you 
might have multiple participants, including a database, another bean, and 
another server on the network. Once you’ve told everyone to commit, 
there’s no good way to undo it, so before you give the signal to commit, 
you need to make sure that everyone can do what you’re asking. As the 
transaction manager, your job is to find out if everyone is ready to perform 
(update the database, debit the account, etc.), and then, depending on the 
results, tell them all to do it (commit) or tell them all to forget it (rollback). 


Phase ONE 


Phase TWO 



Transaction 

Participant 



Transaction 

Participant 
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transaction propogation 


How it works iwEJP 

Transactions can propagate through method calls 

When a bean is running code in a transaction, and calls a method on another bean, 
three different scenarios are possible: 

A) The called method runs in the caller’s transaction. 

B) The called method runs without a transaction. 

C) The called method runs within its own new transaction. 


④ The transaction started in the first method propagates to all other 
methods in the call stack. All called methods run within the same 
transaction. (In this book, we’ll abbreviate “transaction” to “tx ”.） 

foo() bar () 




go() 

C3 





% 





3 




Bean Ts go() method starts 
a transaction (tx A). 

Bean 1 calls method 
foo() on Bean Z, and the 
transaction is propagated 
into the method call on 
Bean 2. 


Bean 2's foo() method runs in 
the transaction from Bean 1 
(tx A) and calls method bar() 
on Bean 3. The transaction 
(tx A) is propagated into the 
method call on Bean 3. 


Bean 3's bar() method runs 
in the transaction (tx A) 
propagated from Bean 2. 

If a system exception (like 
EJBException) happens in any 
of the methods in tx A, the 
whole transaction rolls back. 



tx A 



tx A 
tx A 



tx A 
tx A 

tx A 


So, what does it mean for multiple methods to run in the same transaction context? That 
depends on the bean type and what the beans do in their code. For example, imagine 
Bean A has a method with JDBC code that does an update to a database row. If any other 
method in the same transaction causes a rollback, Bean A’s update won’t commit, even if 
the database would have been more than happy to do it. 
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EJB transactions 


Some trawsactiowsdow't propagate 

The caller's transaction might be suspended 

If a transactional bean method calls another method, the called 
method (whether it’s in the same or a different bean) might not run 
in the same transaction. The called method, in that case, will run 
with either a brand new transaction, or with no transaction at all. (In 
a few minutes, we’ll look at how the container decides whether to 
propagate the transaction, run without one, or start a new one.) 


(§) The first transaction is suspended and the second method 
runs without a transaction. 


Bean 、 



foo() 


tx A 





(no tx) 


丁一 S : 仏。。 ° 一 

a tva 飧 




tx A 

suspended 


⑥ The first transaction is suspended and the second method 
runs within a new transaction. 


foo() 





S : 二 
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using frarisacf/ons 


How do I make (or get) a trawsactiow? 

Two ways: code it or declare it 

The container manages your transactions, but you have to tell it how. You 
can either put transaction code in your bean class, or you can put transaction 
declarations in the DD. By far, the most common approach is to use the 
DD, because it’s simpler, supports bean reuse, and is the only way you can 
do transactions for entity beans. By putting transaction information in the 
DD instead of in code, you can deploy the same bean multiple times and get 
different transaction behavior each time without ever touching the code! 


Bean-managed 
transactions (BMT) 


(7) Write transaction code in your bean. 

<transaction-type>Bean</transaction-type> 


package 

headfirst; 

import 
javax.ejb.*; 
import java. 
rmi. RemoteEx 
ception; 


.java 






UserTransaction ut = context.getUserTransaction() 
ut.begin(); 

// transactional code 

ut. commit () ; ^ 


OR 





CoA7fa//7er-manaqed 
transactions (CMT) 


( 2 ) Declare transactions in the DD. 



encoding 

="UTF-8"?> 


<!DOCTYPE 
ejb-jar 
PUBInc. / 


■xml 


<transaction-type>Container</transaction—type> 

<method> 

<e j b - name>MyBean< / ejb-name> 

<method-name>bar< /me thod-name> 

</method 〉 

<trans-attribute>Required</trans-attribute> 




and CMT in one bean- 

: transaction-type>Bean</transaction-ty P e 
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EJB transactions 


Trawsactiow - related methods 
are iw two interfaces 


Everything in the UserTransaction 
interface is for beans using bean- 
managed transactions (BMT). 


Beans with container-managed 
transactions (CMT) aren’t allowed to 
call ANYTHING in this interface. 


javax.transaction.UserTransaction 

EJBContext has methods for both BMT 
and CMT beans 

For BMT beans only: 

getUserTransaction() 


For both BMT and CMT: 

(all non-transaction-related methods) 


For CMT beans only: 

getRollbackOnly() 

setRollbackOnly() 


(Super class of SessionContext, EntityContext, and MessageDrivenContext) 


EJBContext 


getUserTransaction() 


getCallerPrincipal() 

getEJBHome() 

getEJBLocalHome() 

isCallerlnRole() 




setRollbackOnly() i 


getRollbackOnlyQ 

J 


javax.ejb.EJBContext 


UserTransaction 



begin() 
commit() 
getStatus() 
rollbackQ 
setRollbackOnly() 
setTiransactionTimeout() 




Think about the differences between CMT and BMT. 

If tied up and forced to pick one over the other, which 
would you pick? 

□ CMT □ BMT 


Why? What are the pros and cons? 
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BMT transactions 


Making a PMT trawsactiow 

① Get a UserTransaction reference from your EJBContext. 

context.getUserTransaction() 


( 2 ) Start the transaction. 

ut.begin() 

③ End the transaction (commit or rollback). 

ut.commit() 
ut.rollback() 


a 


:驗㈣ 


II look ai -the adiual . Ty.a^a^ iv, ' l- 

Wtiohs laic^ whch wc 

ihc 咖 

public void checkout () throws Exception { / 

UserTransaction ut = context.getUserTransaction(); 


ut. begin(); 


七 his says, w £-tav-t 3 Y)CY/ 


how. 


anotherBean.validateCredit(customerNum); 


checkInventory(); 



6dW 


otW 


办。 








ut • commit () ;4 ： - how wc ^ 




//or ut.rollback () 


doNonTxStuff (); 


(ov-, y/c tould cv\d i-t a \rollka6k) 

this mciliod is called witliout a tv-ahsadtioh. Wt 
匕 ar/ 七七 ell -Pirom this CoAt i-f do/VohT>c£-tu-f-fO 
s-ta\r*ts i*ts ovm *t\rahS3d*tioh. Wtd liavc *to see 七 ha 七 
method *to khov/ -fo\r suve- 
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EJB transactions 


Call stack of the checkout!) method 


ut.begin() is called, and the 
transaction starts. 


ut.beginQ 
一 —— " - 
checkOut() 


tx A 


② 


ut.begin() completes, 
and now the checkoutO 
method is running in a 
transaction (tx A). 



tX A 


(3^ validateCreditO is called and 
runs in the same transaction 
as checkOutQ. 


validateCreditO 



tx A 
tx A 


validateCreditO completes 
(pops off the stack) and the 
checkOutO method is still 
running in tx A. 



tX A 


⑤ 


checklnventoryO is called 
and runs in the same 
transaction (tx A). 



checklnventoryO completes 
and pops off the stack. The 
transaction (tx A) is still 
open. 



tX A 


commitO is called, which 
ends the transaction. 



tX A 


tX A 


commitO completes, and 
now checkOutO is running 
without a transaction. 



notx 


doNonTxStuff() is called 
without a transaction. 

notx 
notx 
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BMT transactions 



Using this code listing, mark the 
matching call stack frames with a 
checkmark if that frame is currently 
in a transaction. We did one in the 
middle for you. 


public void test () throws Exception { 
blue (); 

UserTransaction ut = ctx.getUserTransaction (); 

green (); 

ut.begin (); 

purple (); 

ut.commit(); 

red(); 


void blue () { green (); } 

void green () { } 

void purple () { red(); } 

void red() { } 


start 

test() 



green() 


blue() 


blue() 


blue() 

test() 


test() 


test() 


getUserTrans... 

test() test() 



red() 


Purple() 


test() 


purple() 


commit() 


red() 

end 

test() 

test() 

test() 

test() 

test() 

test() 
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EJB transactions 


Things you must NOT do with PMT 


① A BMT bean must NOT start a transaction 
before ending the current transaction. 

public void go() { 

UserTransaction ut = context.getUserTransaction() 


ut.begin(); 
doStuff(); 
ut. begin () ; 
// more 







Imagine the implications 
of starting a new 
transaction before ending 
the current one. What 
might happen if you were 
allowed to do this? 


Nested transactions 
are not allowed in EJB! 

Y 0U ，re expected to know what the 
term “nested transaction ,> means, 
and what it might look like in code. 


② A BMT stateless session or message-driven bean 
must NOT complete a transactional method 
without ending the transaction. 

public void go() { 

UserTransaction ut = context.getUserTransaction() 



ut.begin() 
doMore () 


TW.s is a 卜 

‘办。 七寸 气二二 : to — 饮 ' ro '''° atk0 ' 

o-tV»ev 'Nords, 七 h'vy «。 


°：Zs^ TEFUL — 



transaction 


can leave 


a 


end of 


a 


open at the 


Why are stateful session 
beans allowed to end a 
method without ending the 
transaction? 

For a stateful bean, can 

I you think of a scenario 
where you might want 
to do this (leave the 
transaction open)? 

What might go wrong if 
you do this? 


method 
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BMT transactions 


PMT trawsactiows arc om way: 
they caw propagate out to a CMT 
beaw, but wo other trawsactiow 
caw propagatemtoa PMT bean 


Both BMT and CMT bean 
transactions propagate 
into a CMT bean. 


CMT bean 


BMT bean 





A CMT bean can run in 
transactions coming from 
both CMT and BMT beans. 

To the called CMT bean, it 
makes no difference how (or 
by whom) the transaction 
was started. 


A BMT bean will NEVER use any 
other bean’s transaction! The caller’s 
transaction will be suspended. 


CMT bean 


BMT bean 







The only transaction a BMT 
bean will run in is one that the 
bean itself creates. 
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EJB transactions 


What does it mean to suspend 
a trawsactiow? ^ 

If a transaction is in progress when a method on a BMT 
bean is called, the transaction is suspended. Temporarily. 
The transaction just sits there waiting for the BMT bean 
to complete its work. Work that’s not part of the caller’s 
original transaction. Once the BMT method finishes and 
is popped off the stack, the original transaction kicks 
back in, right where it left off. 

Imagine this scenario: a CMT bean, bean one, is running 
a method foo() in a transaction (tx A) when it calls a 
method bar() on bean two (a BMT bean). Once bar() 
completes and pops off the stack, method foo() invokes 
another method, bee(), but this time the called bean is 
another CMT bean (bean three). 


\^iena transaction is 
suspended, it waifs until it 
can pick up wliere it left 
off. Butiliis means ihatilie 
teigs that Kappen wMe 也 e 
transaction is suspended are 
NOT partofilie same atomic 
unit. In other words, ike 
toigs that happen wMe the 
transaction is suspended won't 
be rolled back if ike suspended 
transaction (after it comes 
back to life) fails to conunit. 




BMT bean 
suspends tx A and 
runs bar() in a new 
transaction, tx B. 


CMT bean gets the 
transaction and runs 
bee() in tx A. 



tx A 



txB 

txA 

suspended 



① 


Method foo() of a CMT bean 
is running in transaction A. 
Method foo() then invokes 
method bar() on a BMT bean. 


( 2 ) Method bar() suspends 
transaction A, and starts a 
new transaction, B. Method 
bar() runs in the new 
transaction B,then completes. 


③ 


When method bar() com¬ 
pletes, foo() resumes and 
picks up transaction A again. 
It then calls method bee() 
on bean three (a CMT bean). 
Method bee() runs in foo()’s 
existing transaction (A). 
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the UserTransaction interface 


The UscrTrawsactiow interface 

(javax.transaction.UserTransaction) 



The UserTransaction interface has six methods for 
the things a BMT bean might want to do.Try to figure 
out the method names, based on the description of 
what you want to do. (The answers are at the bottom, 
upside down, so don’t look down there.) 



Begin a transaction 


ut. 


(2) End a transaction 

ut. _ 

//or 

ut._ 

(§) Mark a transaction for rollback 

ut._ 

(4) Find out the status of the transaction 

ut._ 

(§) Set the transaction timeout 

ut. 


^ZT b S e CUon is 

= bea " 
to (0r try 
〜咖 S:: n " Ce to a 


UserTransaction 


m — 

WIUST 


tor en … j — 
entity beans 
be CWIT, if you 讲 

UserTransaction ^ 

一〜备 bean, y° u 


NOT 
Since 


is 


code 





There’s nothing about transaction 
timeout on the exam. 


All transactions have some default timeout value, 


but you can change that with: 

setTransactionTimeout(anlntValue). As a bean developer, 
you’ll probably never use anything but the default timeout 
value, so we don’t test for it on the exam. 


()ino8oj!j_uo!pesuai 丄 19S _g ‘()sn 诉 $ 抟 6 卞 
‘() 人 |UQ>peq||oyi8S x ‘()>peq||auo Oiiluluoo z ‘() u ! 向 q ■[< 
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EJB transactions 



setRollbackOnlyO 

The sound of a transaction's death 

When a bean calls setRollbackOnly() it means 
that transaction is going down. Once you invoke 
setRollbackOnly(), the transaction is doomed to never，ever 
commit. 



So, what does it mean to sentence a transaction to 
death? It means the transaction definitely won’t 
commit. Duh. But it also means that any participant 
in the transaction (i.e. any bean) can check to see if 
the transaction is already marked for death. 

Remember, a transaction started by a BMT bean 
might propagate to method calls that the BMT 
bean makes on CMT beans. A CMT bean in a 
BMT-started transaction might want to sentence the 
transaction to death, or at find ^whether it’s 
already doomed. 

In a CMT bean, setRollbackOnly() is how you tell the 
container that it must not commit the transaction. If you 
can figure out in your business logic that a transaction 
is going to end badly, call setRollbackOnly(). The 
container won’t end the transaction at that point, but 
when it does end at its natural time, it definitely won’t 
commit. 

So, when does a transaction end? Assuming no System 
Exceptions are thrown, a transaction ends when the 
CMT method that started the transaction completes, or 
for a BMT bean, when the bean’s code calls commit() or 
rollback(). 


Ifs tragic. 

When you call the 
setRollbackOnlyO method, 
you set a flag that can 
tell other beans that the 
transaction will end only 
one way... horribly. 

If you know, in your code, 
that things aren't going to 
work, call this method. 

If the transaction is going 
to die, it’s probably for the 
best. It was meant to be. 
Ifs going to a better place. 


c.av' 


tal\ 







Bean A 
starts tx Z 


a method in 
Bean B is called, 
and runs in tx Z 


Ft 


a method in 饮 a - . ». >i , 4 - be 州 “ *飞 . 

Bean C is called, ^ ^ 


and runs in tx Z 


d 
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the setRollbackOnlyf) method 


I*m still missing 
something here... if I'm 
using BMT, why would I call 
setRollbackOnlyO, when I can 
just call rollback() and end it 
right there? 



You might know HOW a BMT transaction should end 
before it’s time to actually end it. 


In your BMT code, you might have a single place at the end of the 
transactional code where you say either ut.commit() or ut.rollback。. 
That single place might be a simple if test: 


if (thingsLookGood) 
ut. commit (); 
else { 

ut.rollback(); 


A ^ ^ or 
based ⑽ sowC 60 


But if somewhere earlier in your code you can tell that the transaction 
is doomed, you should call setRollbackOnly(): 

if (thingsLookBad) { 

ut.setRollbackOnly(); 

} 

This gives other transaction participants a signal (if they care to 
check) that the transaction is already doomed. 


Even if your BMT code doesn’t call setRollbackOnly(), some other 
code in the transaction could have, so you might want to find that 
out. (In just a few more pages from now, we’ll learn how a bean can 
check whether anyone has marked a transaction for rollback.) 
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EJB transactions 


setRollbackOwlyO lives m TWO iwtcrfaccs 


UserTransaction 


begin() 
commit() 
getStatusf) 
rollback() 

setRollbackOnly() 

setTransactionTimeoutQ 




Everything in UserTransaction 
is for BMT beans ONLY! 


EJBContext 

getCallerPrincipal() 


getEJBHome() 


getEJBLocalHome() 1 


getRollbackOnly() I 


getUserTransactionf) 

1 

isCallerlnRoleQ 


setRollbackOnlyO 


setRollbackOnlyf) in EJBContext 
is for CMT beans ONLY! 


The methods in the UserTransaction interface are 
for BMT beans only; CMT beans can’t use anything in 
U serTransaction. 

The EJBContext interface, on the other hand, is 
for both BMT and CMT beans, except for the two 
transaction methods. 

The setRollbackOnly() and getRollbackOnly() 
methods in EJBContext are off-limits to BMT beans. 

Bottom line: BMT beans call setRollbackOnly() on a 
UserTransaction; CMT beans call setRollbackOnly() 
on an EJBContext. 

^^^ 

lode 巧 二 tS ihe a ；；^^° U 

ut rollback()-F° f hgve an app P m no w). 

^ 1 


Be SURE you 
j^now the rules 
for BOTH of the 

m e e t th°otr kOn，y0 

贿 and CM ;== 0 _ 骱 both 

EJBC ^textsetRollbackOnly() 
UserTran ^ction.setRollbackOnly() 

咖 BOTHof these ! 6 ^ 6Ver 

yS°nledto fiof 6 exam P' es where 

f^ p/e , yo ,^ 
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getRollbackOnlyf) method 


getRollbackOnlyO 

because life's too short for a bean to waste time 


Once a bean has called setRollbackOnly(), the transaction 
is sentenced to death. It will never commit. But the 
transaction might still have a long way to go, with plenty of 
other methods in other beans, and with lots of heavy code. 

Imagine you’re a bean. How would you feel if the 
transaction were already doomed before your methods 
were called, but nobody told you? 


Oh, 

like I don’t have 
BETTER things to do than 
run my 2,000 lines of code, 
when ifs already a Dead 
Transaction Walking? 


CMT beans call 

ge£RollhactOnly() to 
find out if ilie transaction 
they’re in is already 
doomed. If the transaction 
is never going to commit, 
should ike bean waste 
time with lots of code? 


If you’re a CMT bean, you can call getRollbackOnly() to find 
out if your transaction has already been sentenced to death. 
If it has, why bother doing any work? 

if (!getRollbackOnly()) { 

saveWorld(); 

} else { 

abandonAllHope(); 

} 
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PMT beans use qetStatusO instead of getRollbackOnlyO 


UserTransaction 


EJBContext 

begin() 

commit() 

getStatus() 乂 ’ 

rollback() 

setRollbackOnly() 1 

setTransactionTimeout() 

getCallerPrincipalf) 
getEJBHomef) ■ 

getEJBLocalHome() IBP 

getRollbackOnly() 

getUserTransaction() 

isCallerlnRoleQ 

setRollbackOnly() 

There’s no getRollbackOnlyf) 
in UserTransaction. BMT beans 


call getStatus() instead. 

getRollbackOnlyf) is for CMT 
beans only. 


The getRollbackOnly() method returns a boolean — true if the method has 
been marked for rollback, false if nobody’s asked for a rollback. That’s all a 
CMT bean can (and needs) to know about the transaction’s status. 

BMT beans, on the other hand, are more involved in controlling the 
transaction, and they might want to know a lot more. The getStatus() method 
in UserTransaction can tell you anything you’d ever want to know, and so 
much more, about how the transaction is doing. 

c Jo 


Jf You don’t need to memorize the status constants. 

The getStatus() method returns an int representing a constant 
for things like: STATUS—ACTIVE ， STATUS—COMMITTED, STATUS— 
COMMITTING, STATUS—THINKING—ABOUT_COMMITTING (just kidding on this one), 
STATUS—MARKED—ROLLBACK ， STATUS—ROLLING—BACK，and our personal and 
most useful favorite, STATUS_UNKNOWN. 

These constants are defined in the javax. transaction. Status interface (which has no 
methods, just a pile of these status constants), and you might find them helpful if 
you’re writing BMT code. But they’re not on the exam. You DO need to know that the 
getStatusf) method is in UserTransaction, and that it’s the only way a BMT bean can 
find out if somebody called setRollbackOnlyQ, but that’s it 
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BMT can hurt reuse 


PMT can be a really PAP idea. 

PMT hurts bean reuse 

Can you figure out why? 

Think about what you learned on the last few pages, especially about transaction 
propagation (the whole one-way thing). 

If you write a BMT bean, nobody else can ever include 
your bean in their transaction! 

Your BMT bean puts up a big fat wall so calling transactions can’t pass. Remember, 
a BMT bean will run only in the transactions the bean itself creates and starts. You 
defeat the whole point of a component model if you lock down the transaction 
demarcation inside the bean. Remember, the cool thing about a component model is 
that components can be mixed and combined in new ways to make new applications 
that the Bean Provider hadn’t ever thought about. The purpose of the deployment 
descriptor is to give the application assembler a way to configure transactions specific 
to a particular application, without touching the bean code! 

If it’s so bad to use BMT, why is it there? 

Because it lets you do a few things you simply cannot do with CMT. But most of the 
time, you won’t need these things. 

With BMT, you can reduce the scope of a transaction. 

Using CMT, you cannot mark a transaction at anything smaller than a single method. 
You put in the deployment descriptor which transaction attribute (we’re getting 
there) goes with which method. You can’t specify a part of a method. But with 
BMT, you can start the transaction and end it at a smaller scope. This can improve 
performance because the longer a transaction lasts, the more likely you are to hurt 
your concurrency. But the tradeoff — hurting your reuse — is almost never worth it, and 
there are usually much better ways of increasing the performance... 

With BMT, you can leave a stateful session bean transaction open across 
multiple invocations from the client. 

With BMT, you can open a transaction (call ut.begin()) in one method, and end the 
method without ending the transaction. (A big no-no for message-driven or stateless 
session beans.) But this is almost always a really bad design idea, so it’s probably never 
going to be a good reason for BMT. 

With BMT, you separate transaction commit status from message 
acknowledgment. This might be a good reason for BMT. 

We covered this in more detail in the MDB chapter, but the short version is: with CMT, 
message acknowledgment is sent only when (and if) the transaction commits. In some 
designs, you can end up with poison messages. 
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EJB transactions 


Contamer-managed trawsactiows 


I manage 

your transactions by 
looking at what you put in the 
deployment descriptor for each method. 
If your method needs a transaction, I’ll 
start one or add you to the callers, 
depending on the attributes. I can even 
suspend a transaction if you need to 

run without one. 


Now that we’ve looked at the do-it-yourself way to demarcate 
transactions, you’ll see how easy it is with CMT. So easy that 
you don’t write anything transactional in your code except 
maybe an occasional call to EJBContext.setRollbackOnly() or 
EJBContext.getRollbackOnly(). 


U 


With CMT, transactions are started and completed (with 
either a commit or rollback) by the container, based solely 
on the deployment descriptor. You (OK, technically 
the Application Assembler) mark some attributes in the 
deployment descriptor and that’s it. 

Almost. 

Unless you understand exactly what the six transaction 
attributes are, and the implications of how different attributes 
interact at runtime, you won’t have a clue about whether your 
bean is even going to be in a transaction. Or, how big the 
transaction will be. Or, whether you’ve created a dangerous 
situation that could blowup at runtime. 

Fortunately, there are only six. And the rules for how the 
container behaves with each of those attributes is very clear 
and simple. 
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transaction attributes 


How attributes work 

① Mark a method with one of six 
transaction attributes: 


Required 

FooBean 


RequiresNew 

setFoo() 

Rc^uiv-cd 

Mandatory 

getFoo() 


Supports 

doBar() 

^ C( \ ui ^cd 

NotSupported 

doBigThingQ 

1 

Never 




② When the method is called, the 
container uses the attribute to do 
one of five things: 

■ Run the method in the caller’s 
transaction. 

OR 

■ Suspend the caller's transaction and 
start a new transaction. 

OR 

■ Suspend the caller’s transaction and run 

the method a transaction. 

OR 

■ Throw an exception because the caller 
does not have a transaction. 

OR 

■ Throw an exception because the caller 
does have a transaction. 


void go () { 

aFooBean.setFoo(); 


Let's see... the 
go() method is already in a 
transaction when it calls setFoo() 
and setFoo() has a Required tx 
attribute, so I will run setFoo() in 
the same transaction as goQ 
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EJB transactions 



As an Application 
Assembler, I have to 
know my attributes so that I 
can get the behavior I desire 
from my beans. 


Is the calling method in a transaction? 


public void foo() { 
aBean.bar(); 


( oo 0 \s m a A) 

»*b tails bavO on a^ottcv- 
bca ,. TV, C ba,0 ^od .s 
marked asRc^rcd^ 


① Method foo() is in a transaction (tx A). 


Know your attributes 

How an attribute affects behavior depends on 
one thing: 


^ooO NOT bee, i, , ^slt 

卜〜 W Wo “| 〜 s c 


(g) Method bar() is marked with the Required 
transaction attribute. 

<method> 

<e j b -name>MyBean< / ejb-name> 

<me thod-name>bar< /method-name> 

</method 〉 

<trans-attribute>Required</trans-attribute> 

The bar() method runs in the caller’s transaction (tx A). 

tx A 
tx A 
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attributes that require a transaction 


Transaction attributes that 
require a transaction 


Attribute for bar() foo() transaction status 


result 


Required 


If the method is called 
with an existing 
transaction context, the 
method runs in that 
existing transaction. If 
there isn’t a transaction, 
the container will start a 
new one. 



in transaction A (tx A) 



tx A 
tx A 


bar() runs in tx A 



no transaction 



container starts a new transaction 
(tx A) for bar() 


RequiresNew 


The method will 
always run with a new 
transaction. If the 
method is called with 
an existing transaction 
context, the caller’s 
transaction is suspended 
until this method 
completes. 



in transaction A (tx A) 


tx B 
tx A 

container suspends tx A and starts 
a new transaction (tx B) for bar() 




no transaction 


tx A 


container starts a new transaction 
(tx A) for bar() 



Mandatory 


Danger! Mandatory 
really means 
“RequiresExisting”. If the 
method is called without 
an existing transaction 
context, the container 
throws an exception! 



in transaction A (tx A) 



tx A 
tx A 


bar() runs in tx A 





no transaction 
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EJB transactions 


Transaction attributes that do 
not require a transaction 


Attribute for bar() foo() transaction status 


result 


Supports 

If the method is called 
with an existing 
transaction context, the 
method runs in that 
transaction. If there isn’t 
a transaction, the method 
runs with an “unspecified 
transaction context.” 




tx A 
tx A 


in transaction A (tx A) 


bar() runs in tx A 



no transaction 



bar() runs with an “unspecified 
transaction context" 


NotSupported 

If the method is called with 
an existing transaction 
context, the caller’s 
transaction is suspended. 
Regardless of whether 
there is an existing 
transaction, the method 
will run in an “unspecified 
transaction context.” 



in transaction A (tx A) 



no transaction 


tx A 

container suspends tx A, bar() runs 
with an “unspecified transaction 
context”. 



bar() runs with an “unspecified 
transaction context" 



Never 

Never means “No Pre- 
Existing”. If the method 
is called with an existing 
transaction context, the 
container throws an 
exception. If there isn’t a 
transaction, the method 
runs with an “unspecified 
transaction context.” 



in transaction A (tx A) 



no transaction 





bar() runs with an “unspecified 
transaction context" 
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transaction attributes 


e^^rpen your pencil 

Know your attributes 

The exam expects you to figure out which combination of attributes can (or will) lead 
to a particular outcome. You might be asked to look at a sequence of methods, where 
the methods show which transaction they’re running in, and you have to figure out 
which combination of transaction attributes could make that scenario possible.They 
might be formatted something like this... 

(The answers are at the bottom of the next page.) 



Tx foo 


QUESTION: Which two combinations of attributes would make this possible? 

1) R-Supports, S-Required,T-Mandatory, U-NotSupported, V-Never 

2) R-RequiresNew, S-Required,T-Required, U-Never, V-NotSupported 

3) R-RequiresNew, S-Supports,T-Supports, U-NotSupported,V-Supports 

4) R-Requires, S-Mandatory,T-Mandatory, U-Supports, V-Never 

5) R-RequiresNew, S-Required,T-Required, U-NotSupported,V-NotSupported 
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EJB transactions 


arpen your pencil 

For the exam (and bean developer life in general) you have to know some REALLY 
important rules about transactions, and it will be much easier for you if you take 
the time now to figure some of this out for yourself. Understanding is much 
better than memorizing, and it’s not like you don’t have enough to memorize as 
it is. You’ll find all of these questions answered over the next few pages, but you 
should really try to do this first. 

Of the six transaction attributes, which one (or ones) must NOT be used by 
a bean that calls getRollbackOnlyO or setRollbackOnlyO? 


( 2 ) Which transaction attribute (or attributes) must NOT be used by a 
message-driven bean? 

(Hint: remember, a message-driven bean doesn’t have a "client”; the container 
invokes the onMessageO method.) 


^ 3 ^ Under what circumstances do you think the container should automatically roll 
back a transaction? 

If the bean gets a runtime exception? 

If the bean throws an application exception? (e.g. InsufficientFundsException?) 


Of the six transaction attributes, three of them can be dangerous, with 
one in particular being EXTREMELY risky. Keeping in mind that the 
Bean Provider is NOT the one who specifies the attributes for the bean’s 
methods, which of the six is potentially the most dangerous? 


9 八 ! j pue 08jqj : U 8 djeqs seinqujiv ©Ml J^msub 
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methods that must have an attribute 


These arc the methods you 

MUST mark with aw attribute 

■ ， _ 

(fora CMT bean) 


Session beans 


■ 


■ 


■ 


Business methods in the component interface 

NONE of the other methods the client sees in 
the component interface (from EJBObject or 
EJBLocalObject) 

NONE of the methods in the home interface, 
including those written by the Bean Provider as 
well as those from EJBHome or EJBLocalHome 




一 ㈣。 ^ 




EJBObject 


getEJBHome() 

getHandle() 

removef) 

isldentical(EJBObject o) 
gerPrimaryKeyQ 


EJBHome 

getHomeHandlef) 
remove(Object pk) 
remove(Handle h) 
getEJBMetaDataQ 


Advice 


getAdvice() 

ignoreAdvice() 


AdviceHome 


createf) 


Entity beans 


■ 


Business methods in the component interface 


■ NONE of the other methods the client sees in 
the component interface (from EJBObject or 
EJBLocalObject) except removeQ 

■ ALL of the home interface methods written by the 
Bean Provider, as well as the remove() methods 
from EJBHome or EJBLocalHome. 

You ^ move ::七 

如於 7 ova Zt) arc a ^ cal ^ 






EJBObject 


getEJBHomef) 

getHandlef) 

remove() 

isldentical(EJBObject o) 
getPrimaryKeyf) 


EJBHome 

getHomeHandlef) 

remove(Object pk) 
remove(Handle h) 

getEJBMetaDataQ 


Customer 


getName() 

setName() 

getlDQ 


CustomerHome 


create 。 

findByPrimaryKey() 

getCustomerList() 


Message-driven beans 


■ 


onMessage() 


A r^cssagc-dv-ivch beah 
i^avc a^y dien 七 

onMessageQ 
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EJB transactions 


Hmmmm.... what happens if 
I use ''Supports ”？ How will I really know 
if there's a transaction? And what about 
NotSupported? Never? What about ejbCreate() 
and ejbRemove() for session beans? What 
happens if I quit my job and become a 
surfing instructor in Kauai? 


Unspecified Trawsactiow Context 


jj 



The term “an unspecified transaction context” is the EJB 
spec’s way of saying, ‘You have no clue. I (the container) 
can do whatever I want and you’ll just have to deal!” 


You must know, for the exam, the methods (and 
circumstances) that might be running in an “unspecified 
transaction context.” 

■ Any CMT method marked NotSupported, Never, or Supports. 

NotSupported and Never are supposed to mean “no transaction”, 
but in reality, the container can do whatever it wants. And with 
Supports, you never know anyway (which is why we think it’s a 
really dumb attribute that nobody should ever use). 


■ CMT session bean methods ejbCreate() (any of them), 
ejbRemove(), ejbPassivate(), ejbActivate(). 

The create and remove methods of a session bean are not 


. t here is that you N0 丁 

guaranteed. 


We think being a snowboard instructor is better 
than teaching surfing. Just as fun, but without all 
that neoprene. Or sharks. 


considered part of a client’s transaction (unlike the way it works 
with entity beans). And remember, activate and passivate will 
never be called if the session bean is in a transaction. 

■ CMT message-driven bean methods ejbCreate() and 
ejbRemove(). 

Remember, for a message-driven bean, ejbCreate() and 
ejbRemove() are called by the container when it wants to add or 
remove beans from the pool. There’s no calling client transaction, 
because a message-driven bean doesn’t have a real client! 

So, is there a transaction or not? Why is it “unspecified ”？ 
Why isn’t it just “definitely no transaction ”？ 

The spec lets the Container do whatever it wants. The 
spec suggests several options, including everything from 
executing without any transaction at all to merging 
multiple calls to a resource manager together into one 
transaction. 
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transaction notes 


Purw these m 


These are all things you might be tested on. But remember, you won’t be 
asked a simple true or false question, like, “The getRollbackOnly() method 
can be called from a method with a transaction attribute of NotSupported.” 
(In which case the answer would be false, of course). No, you’re likely to see 
something much more clever, like bean code plus the bean’s deployment 
descriptor, and you have to decide if it all works together. 


getRollbackOnlyO 
MUST be called 
from a bean in a 

transaction! 

You already know that getRollbackOnlyO 
can be called only by CMT beans, 

n ，加 _ 

can’t ca" getRollbackOnlyO•) 

But for getRollbackOnlyO to : 

method must be in a transactio , 
means you MUST use only. 

Requires 
RequiresNew 
Mandatory 


•k 


•k 


L — 一心 * 

aZn wW H erEXCeption )- Do not ⑽—" 

- ^^ — 


SB^ eans 

Th ^^outit Ame T 二 以 

to use the other ones 〜 nt make an Y sense 


500 


Chapter 9 





EJB transactions 


BMT: You suck. 




THE miBlKH 
LSUNGE 


(Wt a BMT bear\ av\d a 

CtAT av-gumg at tiic bav-.) 


CMT ： Oh, that’s so clever. What a way with words. And what do 
you mean by that? And is it just me personally, or all GMT beans 
in general? 

BMT: All of you. Weenies. You’re not bean enough to handle 
your own transactions, so you leave it all up to the container. 
You’re probably afraid of the garbage collector, too. 

CMT: Weenie? Don’t tell me you actually believe thatjowV^ man¬ 
aging your own transactions? The container is always in charge 
my friend. Same for you as it is for me. 

BMT: That’s not true! / start the transaction and/decide 
if — and when —— to commit or rollback. Where’s the container in 
all that? I mean, sure, the container has to give me the transaction, 
but after that, I’m in charge. 

CMT ： jVb, you’re 細 

BMT ： Tes, I am. 

CMT: All you’re doing is demarcating the boundaries of the 
transaction. You get to say where it starts and stops. End of story. 

BMT ： Uh, you’re forgetting that/have the power to rollback. 

CMT: So do I. 

BMT ： jVb, you don’t. 

CMT ： Tes, I do. What do you think setRollbackOnlyQ is for? 

BMT: You can’t call that. That’s in the UserTransaction inter¬ 
face and that’s off-limits to you GMT peasants. 

CMT: I can’t believe they let you be a bean. You know that E]B- 
Gontext has a setRollbackOnlyQ method just for GMT beans. 

BMT ： Oh. I forgot about that. But so what? You still aren’t in 
control of your transaction boundaries. 

CMT ： But what does that matter? My methods are all marked 
with howl want transactions to be applied, so how is that differ¬ 
ent from controlling the boundaries of a transaction? 

BMT ： HELLO! Your transactions must be at least as long as a 
whole method! I can scope my transactions to something more 
granular than the whole darn method. 

CMT ： But why would you ever want to? 


BMT ： You really have to ask that. OK, let me break it down 
so that evenj ⑽ can understand: transactions hurt concurrency. 
That means they hurt performance and scalability. And that 
means —— 

CMT ： [interrupting] Yeah, yeah I know all that. But without 
transactions, you can’t even run your business. 

BMT ： Duh. I’m not talking about not using transactions. I’m 
talking about keeping them as short as possible. It’s just like the dif¬ 
ference between synchronizing an entire method versus making a 
synchronized block. 

CMT: I m not sure that really matters, but OK. No, wait, if 
your methods are that big, you probably have a bad OO design 
anyway. So if that’s the only benefit to BMT... 

BMT: It’s not. I can do things you can ? t ever do. 

CMT ： For example? 

BMT ： Like open a transaction in one stateful bean method and 
close the transaction in some other method of that bean. 

CMT ： Oh, yeah, like that’s not gonna kill your performance? 
Don’t you know how much that hurts your scalability? That 
prevents your stateful beans from being passivated! You risk 
just leaving the transaction open, like, forever. And how are you 
gonna even guarantee that the method that starts the transaction 
will be called before the method that ends it? Geez, you could call 
commitO or rollbackQ before you ever said beginQ! 

BMT: Yeah but if someone needs to do that, BMT is the only 
way to do it. 

CMT ： Except almost nobody ever needs to do that! Or should. 
OK, yes, I’ll agree that if in the unbelievably and incredibly un¬ 
likely event that a developer needs to do that, you’re the only way. 

But there’s no other reason I can see to use BMT, especially since 
BMT defeats the whole reusable component thing. How arrogant 
can you be? You can never run in anybody else’s transactions! 

Only your own. Talk about “doesn’t play well with others …” 

BMT: Well, OK, maybe I really am just for special occasions, 
but next time we’ll have to talk about preventing poison message- 
driven bean messages. I’m the only one who can do that. 

CMT: Yeah, well, we’ll just have to see about that when we get 
to the MDB chapter. I’m outta here. 
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transactions in the deployment descriptor 


Marking trawsactiows iw the PI? 

All beans must say whether they’re using bean- or container-managed 
transactions. For BMT beans, that’s it for the DD. 


But for CMT beans that’s just the beginning. 


Hey container, I want you to 
take care of everything, so I'll say ： 

<transaction-type>Container</ 
transaction-type 〉 in the DD. 




Sure, I'll manage 
your transactions, but 
you have to tell me HOW. Since 
you said ''container" in the DD for 
transaction-type, I need to know the 
transaction attributes for your 
methods. 



Transaction-related DD info lives in two places 


① For both CMT and BMT beans: 

The 〈 transaction-type〉element in the <enterprise-beans> section 

<enterprise-beans> 

<session> 

• • • 

<transaction-type>Container</transaction-type> 

</session> 

</enterprise-beans> ^ 

② For CMT beans only: 

The 〈 container-transaction〉element in the 〈 assembly-descriptor〉section 

<assembly-descriptor> 

<container-transaetion> 

、 <method> 

/ <ejb-name>MyBean</ejb-name> 

<method-name>bar</method-name> 

</method 〉 

<trans-attribute>Required</trans-attribute> 
</container-transaction> 

</assembly-descriptor 〉 


I could manage my own 
transactions if I wanted to. No, really. 
I just don't want to. But that does NOT 
make me a weenie. 


502 Chapter 9 











EJB transactions 


99 example for CMT 


In the <enterprise-beans> element 

〈 enterprise-beans> 

<session> 

<display-name>AdviceBean</display-name> 

<ejb-name>AdviceBean</ejb-name> 

<home>headfirst. AdviceHome</home> 
<remote>headfirst. Advice</remote 〉 

<ejb-class>headfirst.AdviceBean</ejb-class> 
<session-type>Stateless</session-type> 
<transaction-type>Container</transaction-type> 
〈 security-identity 〉 

<use-caller-identity></use-caller-identity 〉 
</security-identity 〉 

</session 〉 

</enterprise—beans> 


In the <assembly-descriptor> element 

<assembly-descriptor> 

〈 container—transaction 〉 

<method> 

<ejb-name>MyOtherBean</e jb-name> 
<method-name>foo</method-name> 

</method 〉 

<trans-attribute>RequiresNew</trans-attribute> 

</container-transaction> 

</assembly-descriptor 〉 




Cn\ 




S VAV— 4 


You specify attributes by listing a specific attribute (RequiresNew, 
Supports, etc.) and putting in all of the methods that are supposed 
to have that attribute. You might think you’re supposed to first 
specify a method and then give the attribute for that method 
(because that’s how it looks in this example), but that’s not how it 
works. It’ll all make sense on the next page... 
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transactions in the deployment descriptor 


More PI? examples for CMT 


Option 1: Wildcard 

Use a wildcard to say that all methods in the specified bean have the 
attribute in the <trans-attribute> tag. 


<container-transaction> 

<method> 

<ejb-name>BigBean</ejb-name> 

<method-name> * </method-name> 

</method> 

<trans-attribute>RequiresNew</trans-attribute> 

</container—transaction 〉 


Mr 


Option 2: Individually-named methods 

Specify each method of each CMT bean in the ejb-jar (unless you use 
the wildcard to indicate all methods of the specified bean class have the 
specified attribute). 


<container-transaction> 

<method> 

<ejb-name>BigBean</ejb-name> 
<method-name>foo</method-name> 

</method> 

<method> 

<ejb-name>TinyBean</ejb-name> 

<me thod- name>go< /me thod-name> 

</method> 

<method> 

<ejb-name>MyBean</ejb-name> 

<method-name>bar</method-name> 

</method> 

<trans-attribute>RequiresNew</trans-attribute> 

</container—transaction 〉 

<container-transaction> 

<method> 

<ejb-name>BigBean</ejb-name> 

<me thod- name>do Stuff< /method-name> 
</method> 

<trans-attribute>Required</trans-attribute> 

</container—transaction 〉 


Ke<\ui*-esKew attribute. 


丁 WsOK s 0 kvc W W ，、 


IK 巧 






504 Chapter 9 


EJB transactions 


Wait a minute— are you 
telling me I can’t have overloaded 
methods? I don’t see any argument 
lists in there. If all I get to put 
in is the method name, I'm 
screwed. 



0 ^\oaded -^od, 


身，二 Ud 卞加 

a 加岣孙七丁 k U ovnC 


- 


yjt 




to 


°TTa6V ， 'se6W 


\oaded 巧抓 
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Don’t worry. 

Chances are, your design will treat all versions of an 
overloaded method in the same way (for transactions). 

In the examples we’ve seen so far, a method name 
represents all overloaded versions of that method. 

But just in case you do need to distinguish between 
different overloaded methods, there is a way to specify 
the arguments. The optional <method-params> tag looks 
like this: 

<container-transaction> 

<method> 

<ejb-name>ShoppingBean</ejb-name> 
<method-name>addItem</method-name> 

<method-params> 

<method-param>java. lang. String</method-param> 
<method-param>int</method-param> 
</method-params> 

</method> 

<trans-attribute>RequiresNew</trans—attribute 〉 

</container—transaction 〉 

<container-transaction> 

<method> 

<ejb-name>ShoppingBean</ejb-name> 
<method-name>addItem</method-name> 

一 ^ <method-params> 

x*^^__^5r<method-param>int</method-param> 

</method-params> 

</method> 

<trans-attribute>Requires</trans—attribute 〉 

</container—transaction 〉 
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transaction attributes in the DD 


Yes you DO 
need to know 
the tags for 

transactions- 

You’re not expected to memorize 
every tag in the whole DD, but you 
UO need to know how to specify 
transaction attributes, including 
the way you can use the wildcard 
to represent all the methods of 
a bean, and that there IS a \Nay to 
give overloaded methods different 
trdnsdction attributes. 

Be sure you know that transaction 
attributes are NOT specified in 

the <enterprise-beans> part of the 

DD, but rather in the <assembly- 
descriptor> section. Think about 
why that makes sense... a Bean 
Provider has to say (in the DD) 
whether the bean is using BMT 
or CMT, but that’s it The app 
assembler will come along later and 
decide exactly how transactions 
should be handled for this particular 
deployment of the bean. 


Transaction attributes are 
part of application assembly, 
NOT bean development. 


TKat means the attributes are 
Specified in ihe assembly part 
of the DD ratker iJianiniiie 
bean part. 

The only tiling you say about 
transactions in ihe bean part 
is >^ieflier ike bean is using 
Container- or Bean-inanaged 
transactions. 


Can I combine the wildcard with specific method names? I 
mean, what happens if I want to have all the bean’s methods, except 
one use RequiresNew, and just one method to use NotSupported? 

A- 

Jr \ m No problem. Using the wildcard is like saying,"All methods not 
otherwise specified in the DD should use this attribute.” So go ahead 
and use the wildcard for the RequiresNew part of the DD, and when 
you get to the NotSupported attribute, give the method name. 

<container-transaction> 

<method> 

<ejb-name>BigBean</ejb-name> 

<method-name> * 〈 /method-name 〉 

</method 〉 

<trans-attribute>RequiresNew</trans-attribute> 

</container—transaction 〉 

<container-transaction> 

<method> 

<e j b-name>BigBean< / ejb-name> 
<method-name>use01dDatabase</method-name> 

</method 〉 

<trans-attribute>NotSupported</trans-attribute> 

</container — transaction 〉 
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i^^rpen your pencil 


Which methods need transaction attributes? 

This one is a combination of how much you remember, and how much you can 
think through what makes sense. Looking at the interfaces below, one for a 
session bean and one for an entity bean, figure out which methods MUST have 
transaction attributes when the bean is using CM! Put a checkmark by it, circle it, 
run your highlighter through it. But don’t try to simply remember what you’ve seen 
in this chapter... really think about it. 


Session bean 


Entity bean 


EJBObject 

getEJBHome() 

getHandlef) 

removef) 

isldentical(EJBObject o) 
getPrimaryKeyf) 


A 

丄 

Advice 

getAdvicef) 

ignoreAdviceQ 


EJBHome 


getHomeHandlef) 
remove(Object pk) 
remove(Handle h) 
getEJBMetaDataQ 


AdviceHome 



ask YourscUr these 

'uest»o 灼 s : 

氺 Is a reason *t^»s m jod 
MUST be … a *bvair>satW- I s 
\i domj t 

氺 | s hxert a^7 代 as ⑽七 w»s 

should UOT \>t m a 

•bra 灼 


EJBObject | 


EJBHome , 

getEJBHome() 

getHandlef) 

removef) 

isldentical(EJBObject o) 
getPrimaryKeyf) 


getHomeHandle() 
re move (Object pk) 
removefHandle h) 
getEJBMetaDataf) 

t 

Z 


Customer 


CustomerHome 

get N a me () 
set N a me () 
getlDQ 


create () 

findByPrimaryKeyf) 

getCustomerList() 


氺 | s 

should be 乙叫 >1 邮广 

Co^*ta'm^- because »t 
心⑽一 “ W 叫舳 一七七 ^ 
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Summary of Pean-managed demarcation 


Bean-managed (BMT) 


Used by stateless and stateful session beans. 
Used by message-driven beans. 

Must A /07 be used by entity beans. 


■ The UserTransaction interface does NOT have 
a getRollbackOnly() method, but BMT beans 
can call getStatus() to find out if someone in the 
transaction has called setRollbackOnlyQ. 


Can be used to reduce the scope of a transaction, 
which can help performance. 

Can be used to keep a transaction open across 
multiple invocations to a stateful method bean. 

Can be used by a message-driven bean to 
acknowledge a method even though the transaction 
ends in a rollback. 


■ The getStatus() method returns an int representing 
a constant, one of which is STATUS_MARKED_ 
ROLLBACK. 

■ Session beans using BMT must not implement 
SessionSynchronization. 


Message-driven beans must complete a transaction 
by the end of onMessage(). 

Stateless session beans must complete a 
transaction by the end of the business method in 
which the transaction was started. 

The BMT bean must not start a transaction without 
first ending the previous transaction. (Remember, 
no nested transactions in EJB!) 

The BMT bean must not use the getRollbackOnly() 
and setRollbackOnly() methods of EJBContext. 

The BMT bean can call the setRollbackOnly() 
method on the UserTransaction. 

The bean gets a UserTransaction from the bean’s 
EJBContext. 





Make i 士 SiickC ^ 

CMTbeans run 

trans ^ctions unknown 

while BMT beans ’ 

use only their own. 

?o K n? We know * So why 

〜 you create them yourself. b ter when 


Propagation of transactions in a BMT bean are 
one-way: a bean-started transaction can propagate 
out to other beans, but no transaction can ever be 
propagated in to a bean using BMT. 
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Container-managed (CMT) 

Used by all bean types. 

Compulsory for entity beans. 

Transaction attributes are specified in the 
deployment descriptor. 

The six transaction attributes are: Required, 
RequiresNew, Supports, Mandatory, Never, Not 
Supported. 

Transactions can be propagated into and out of a 
CMT bean. 

The CMT bean must not attempt to use BMT, 
including getting a UserTransaction reference. 

The CMT bean must not use the setRollbackOnly 
method of UserTransaction. (Guess you could 
figure that out from the previous bullet point...) 

The CMT bean can use the getRollbackOnly and 
setRollbackOnly methods of EJBContext. 

CMT transactions cannot stay open across multiple 
method invocations from a stateful session client 
(BMT transactions can). 

CMT transactions are scoped at the method 
level. Either the whole method runs in a particular 
transaction context, or it doesn't. 

Calling setRollbackOnly on an EJBContext means 
the container must NOT commit the transaction. 


■ A CMT bean that calls setRollbackOnly() or 
getRollbackOnly() MUST have an attribute of 
Required, RequiresNew, or Mandatory. 

■ A CMT session bean must specify attributes for: 
all business methods in the component interface, 
none of the methods in the home, and none of the 
methods from EJBObject (or EJBLocalObject). 

■ All entity beans must specify attributes for: all 
business methods in the component interface, 
all the methods declared by the Bean Provider in 
the home interface, and any remove() method 
that the client can access (i.e. the ones defined 
in EJBHome, EJBLocalHome, or EJBObject and 
EJBLocalObject. 

■ You probably do not want to use Supports because 
you can’t know for certain whether your bean is 
going to run in a transaction. If you’ve written calls 
to getRollbackOnly() or setRollbackOnly(), the bean 
can get an exception. 

■ A message-driven bean can use only two attributes: 
Required or NotSupported. 
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session synchronization 


Ewtity beans have ejbloadO to stay sywchrowizcd, 
cvcw ifthctrawsactiow rolls back. 



Client calls methods on 
the bean, that change the 
bean's internal state. 


③ 


Container simply does a new 
load on the bean, to refresh 
it with the original data from 
the database. 




② 


Bean has a problem and can’t com¬ 
mit the transaction. But now that 
leaves the bean out of sync with 
the database. The beans limit 
state is 420, but the limit in the 
database is 343, exactly where it 
was before the transaction began. 


Now everything is just 
like it was before. As if 
nothing ever happened... 


④ 


Bean is happy, and now all of its 
persistent state matches the 
entity’s data in the database. 
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Session Sywchrowizatiow 

because session beans don't have ejbLoad and ejbStore 

The point is this: 

An entity bean has ejbLoad () and ejbStore () to tell it when to 
synchronize with the database. If the transaction is about to commit, 
ejbStore () is called to give the bean one last chance to get it’s 
persistent state in order, ready to be written to the database. And if 
the transaction does not commit, the bean just gets another ejbLoad () 
to return it to its original pre-transaction state, and everything is fine. 

But a session bean doesn’t have that luxury. No ejbLoad() or 
ejbStore () to tell it when it’s time to synchronize itself with a database. 
But if your session bean implements SessionSynchronization, you can 
give a session bean three new container callbacks, that notify the bean 
of three more special moments in the bean’s transactional life: when a 
transaction starts, when it’s about to end, and when it’s over. 


SessionBean interface 

(javax.ejb.SessionBean) 


SessionSynchronization interface 

(javax.ejb.SessionSynchronization) 


〈〈 interface 》 

SessionBean 


《 interface 》 

SessionSynchronization 

setSessionContext(SessionContext sc) 


afterBeginf) 

ejbActivatef) 


beforeCompletion() 

ejbPassivate() 


afterCompletion(boolean committed) 

ejbRemove() 





setSessionContext( SessionContext sc) 

ejbActivate() 

ejbPassivate() 

ejbRemove() 

afterBegin() 

beforeCompletion() 

afterCompletion(boolean committed) 

II business and create methods 


A session bedh irif»plcrwCh*t 

BOTH -the 

£cssioh£yh^iivohi23*tioh 

(or a *fco*tal o-f 1 me 七 hods *to 

implement 
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SessionSynchronization callbacks 


SessionSynchronization "special momcwts" 


C MORE special ^ 
V moments? ( 


siaicful ^ 

CMT 


o 





afterBeginQ 


beforeCompletion() 


afterCompletionQ 


a 

When it’s called 

At the beginning of a stateful 
bean’s transaction, BEFORE 
the business method that’s 
going to run in the transaction 
is called. 

Just before the transaction 
ends, AFTER the business 
method completes. 

After the transaction has ended 

either in a commit or rollback. 
The method passes a boolean 
argument to tell you whether 
the transaction committed. 

Which entity bean 
method it’s most like 

ejbLoad() 

ejbStore() 

Nothing in the entity bean 
lifecycle corresponds to this. 
(Because there’s no need.) 

What to do when 
you’re in it 

Load in data from the database, 
knowing that the database 
resource is now part of the 
transaction, so you can cache 
the data in the bean for the rest 

of the transaction. 

Last chance to update the 
database before the transac¬ 
tion commits, and the locks on 
the database are released. 

Find out how the transaction 
went, and do whatever you have 
to do to stay synced with the 
database. For example, if you 
were caching newly-changed 
data in temporary variables, you 
can now assign the temporary 
values to your permanent state 
variables.Or if the transaction 
rolled back, you might have to 
reset some values with data 

from the database. 

Bean things you can 
do while you’re in it 

Call methods on your 
SessionContext: get your 
home, get your EJB object, get 
caller security info, force the 
transaction to rollback, check 
the rollback status. 

Access: your special JNDI 
context, resource managers, 
and other beans. You’re in a 
transaction, so it’s all safe! 

You 1 re still in a transaction... 

so you can do the same things 
you can do in afterBegin(). 

Call methods on your 
SessionContext: get your 
home, get your EJB object, get 
caller security info. You can’t do 
any transaction-related things 
because you } re no longer 
in a transaction! You can ac¬ 
cess ONLY your special JNDI 
context. It’s not safe to access 
resource managers or other 
beans. 
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Stateless session 
beans can，t implement 

SessionSynchronization! 

Only stateFUL session beans can /mp/emenf 
SessionSynchronization, because stateless 
session bean’s aren，t allowed to maintain a 
transaction once a method has ended. 


methods so that m0ment ” callbac k 

普 :? f BMT 匕咖 knows 

because the bean is the and ends > 

transaction boundaries. demarcatin 9 the 

starts addends! SayS Wh ° n the trans ^ctio n 

^ been needs to & — 


_t]i©reiareaip 

Dumb Questions 


If you want synchronization so 
badly, why not just use an entity bean? 


A ： 


Because your bean might 
represent a process, and not an entity. 
Not everything that involves database 
data is an entity! If your session bean 
represents a process, like a shopping 
session, but it still uses a database,you 
might want to wait until the transaction 
is complete before updating information 
in the database. 

On the other hand, using a session bean 
as as a "poor-man’s entity bean" Just for 
the sake of avoiding entity beans, is silly. 

If you need an entity, make it an entity 
bean and get all the advantages the 
Container has to offer, like automatic 
synchronization with the persistent 
store. But if your bean is a process, but 
still needs to stay on top of how the 
transaction is going, you’ve got the 
option with SessionSynchronization (as 
long as it’s a stateful, CMT bean.) 
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P00I Puzz]e 



Your job is to take code snippets from the 
ool and place them into the blank 
lines in the code. You will use each 


snippet exactly once. 


Your goa/ is to make a method in 
a BMT bean that will create a total of 


five transactions. But wait, there’s more! 
Exactly TWICE during this method, a 
transaction will be temporarily suspended. 
(We won’t tell you whether it’s the same 
transaction suspended twice, or two 
different transactions.) Any method with 
"cmt" in its name is from a CMT bean, and its 
transaction attribute is revealed in its name. 


Assume that the variables "c"and "ut" 
have been properly initialized as instance 
variables. 


Oh yeah, you must NOT throw any 
transaction related exceptions! 

(Answers are on the next page, so don’t look, 
unless you have absolutely no concern for 
the loss of self-esteem that you’ll experience 
by going straight for the answers.) 


void bmtMethodWithTransactions () 


c.cmtRequiresNew ()； 



Note: Each snippet 
from the pool can be 
used only once! 


ut.commitO; 

c.cmtSupportsO; 

c.cmtRequiredQ; 


c.cmtMandatoryO); 

c.cmtRequiresNewO; 

ut.commitO; 


c.cmtMandatory); 


ut.begin(); 


c.cmtNotSupportedQ; 


514 Chapter 9 























EJB transactions 


P^l puzz]c 

(Which of course you won’t be looking at until 
you’ve completed the puzzle on the previous page.) 


^°c 

f (升 IU4U40? •干 1 


f(() 人 *AO 押 

pOlfpW4 SViOlAJJkl M31J/A p?pM3 乂乂 + 

f() 中 

fQM|6?C|^ 


汾 ' M?.? 

OM 盼 S 


OM "qs 

f()p 中。以⑺。价 w? 

乂 + OM /AOM 

uoi^vesue^ p^e ^ pu^svis ^ ^ 

(p^li'MOV pOH^.3W4 SV)OI 八 3Jkl UJIJ/A p3pM3 乂 +) | 乂 + 

| 乂 + pM^SViS ^ ^ 

f (升 |vuvu 07 .?i 
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1^ 
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coffee cram mock exam 


"TKcck Sxom 


Which are true about transactions in EJB 2.0? (Choose all that apply.) 

[I A. EJB containers must support both JTA andJTS. 

Q B. EJB 2.0 supports nested transactions. 

□ C. The javax. transaction. UserTransaction API allows you to set 

isolation levels. 

口 D. A bean instance can run multiple transactions in parallel. 

Q E. A message-driven bean instance must complete a transaction before the 
4 onMessage , method returns. 


When using BMT demarcation, which of the following must commit a 
transaction before the method that initiated the transaction returns? (Choose 
all that apply.) 

Q A. message-driven beans 
Q B. stateful session beans 
Q C. stateless session beans 
口 D. none of the above 


Which two are true about container-managed transactions in EJB 2.0? 

(Choose all that apply.) 

Q A. Differentiating between overloaded methods is possible in the bean’s 
deployment descriptor. 

Q B. Every business method in the bean class must have a transaction 
attribute. 

[1 C. If an onMessage() method returns before committing a transaction the 
container will throw an exception. 

口 D. A message-driven bean with CMT demarcation must not invoke the 
EJBContext.getUserTransaction() method. 
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What’s true when specifying transaction attributes in the deployment 

descriptor? (Choose all that apply.) 

Q A. For session beans, transaction attributes can be applied only to 
methods in the bean’s component interface. 

Q B. The 〈 method-name〉tag can take a wild card. 

口 C. A single method can have multiple transaction attributes specified in 
the deployment descriptor. 

Q D. Transaction attributes must NOT be specified for methods in an entity 
bean’s home interface. 


5 


Which transaction attributes can cause an in-progress transaction to be 
suspended? (Choose all that apply.) 

口 A. NotSupported 

Q B. Required 

Q C. Supports 

Q D. Re quire sNew 

Q E. Mandatory 

Q F. Never 


The use of which transaction attribute can cause a 

j avax. transaction. TransactionRequiredException exception to be 
thrown? 

Q A. NotSupported 
Q B. Required 
口 C. Supports 
Q D. Re quire sNew 
Q E. Mandatory 
Q F. Never 
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7 


If a set of CMT bean methods has the following transaction attributes: 

Method-1 = Supports 

Method-2 = Required 

Method-3 = NotSupported 

Method-4 = RequiresNew 

In the diagrams that follow, an arrow indicates that the method on the 
left calls the method on the right, and the “tx” number indicates a unique 
transaction. Which diagrams work with the transaction attributes listed above? 
(Choose all that apply.) 


□ A. Ml (Tx 1) ->M2 (No Tx) -> M3 (No Tx) -> M4 (Tx 2) 

□ B. Ml (No Tx) —> M2 (Tx 1) 

\ \ — >M3 (Txl) 

\ —— > M4 (Tx 2) 

□ C. Ml (No Tx) -> M2 (Tx 1) -> M3 (No Tx) 

\ — > M4 (Tx 2) 

□ D. Ml (Tx 1) -> M2 (Tx 1) -> M3 (Tx 1) -> M4 (Tx 2) 

Which methods of a session bean, with container-managed transaction 
demarcation, run in an unspecified transaction context? (Choose all that 
apply.) 


□ A. e jbActivate () 

□ B. ejbPassivate () 

口 C. Business method marked 'NotSupported’ 

□ D. ejbRemove () 

口 E. Business method marked ‘RequiresNew’ 


If a session bean’s business method invokes 

EJBContext. setRollbackOnly () , which transaction attribute settings can 
cause the container to throw the java. lang. IllegalStateException? 

(Choose all that apply.) 

口 A. NotSupported 
Q B. Required 
口 C. Supports 
Q D. RequiresNew 
Q E. Mandatory 
Q F. Never 
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Which method can be called successfully by a bean using bean-managed 
transaction demarcation? 

□ A. getUserTransaction() 

□ B. afterBegin() 

□ C. afterCompletion() 

□ D. getRollbackOnly() 
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c 办尹 尹它它 


Sx^K 


Which are true about transactions in EJB 2.0? (Choose all that apply.) 


T^C 1 ) 


□ 
□ 
□ 

□ 

[/ 


A. EJB containers must support both JTA and JTS. 

B. EJB 2.0 supports nested transactions. 


iust Uscv-Trahsad-tio^ -fv-om JTA 


C. The javax. transaction. UserTransaction API allows you to set 

isolation levels. — No 

D. A bean instance can run multiple transactions in parallel. 

E. A message-driven bean instance must complete a transaction before the 
‘onMessage’ method returns. - Y«s| 


When using BMT demarcation, which of the following must commit a 
transaction before the method that initiated the transaction returns? (Choose 
all that apply.) 


(s ? e6 ： WO - 州 ) 


4 


A. message-driven beans 
Q B. stateful session beans 
^ C. stateless session beans 
口 D. none of the above 



ij Which two are true about container-managed transactions in EJB 2.0? 
(Choose all that apply.) 


A. Differentiating between overloaded methods is possible in the bean’s 
deployment descriptor. 

B. Every business method in the bean class must have a transaction 
attribute. 


7s ? e6 ： 狹-糾 




Q C. If an onMessage() method returns before committing a transaction the 
container will throw an exception. 


No 


4 


D. A message-driven bean with CMT demarcation must not invoke the 
EJBContext.getUserTransaction() method. 
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5 


What’s true when specifying transaction attributes in the deployment 
descriptor? (Choose all that apply.) 


(s_: 扔卜祈 ) 




A. For session beans, transaction attributes can be applied only to 
methods in the bean’s component interface. 

b. The <method-name> tag can take a wild card. 

Q C. A single method can have multiple transaction attributes specified in 
the deployment descriptor. 

口 D. Transaction attributes must NOT be specified for methods in an entity 
bean’s home interface. 一 七 be 

Which transaction attributes can cause an in-progress transaction to be 1 

suspended? (Choose all that apply.) 

3 A. NotSupported 

Q B. Required 

口 C. Supports 

Hf D. RequiresNew 

Q E. Mandatory 

Q F. Never 


6 


The use of which transaction attribute can cause a 

javax. transaction. TransactionRequiredException exception to be 
thrown? 


(s ? e6 ： 抝 - 洲 ) 


□ A. 

□ B. 

□ C. 

□ D. 
^ E. 

□ F. 


NotSupported 

Required 

Supports 

RequiresNew 

Mandatory 

Never 
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9 


If a set of CMT bean methods has the following transaction attributes: 
Method-1 = Supports 
Method-2 = Required 
Method-3 = NotSupported 
Method-4 = Re quire sNew 

In the diagrams that follow, an arrow indicates that the method on the 
left calls the method on the right, and the “tx” number indicates a unique 
transaction. Which diagrams work with the transaction attributes listed above? 
(Choose all that apply.) 

□ A. Ml (Tx 1) -> M2 (No Tx) -> M3 (No Tx) -> M4 (Tx 2) 

□ B. Ml (No Tx) —> M2 (Tx 1) 


( s ? e 6： 抝肩) 


[/ 


\ \ — >M3 (Txl) 

\ —— > M4 (Tx 2) 

C. Ml (No Tx) —> M2 (Tx 1) -> M3 (No Tx) 

\ — > M4 (Tx 2) 


□ D. Ml (Tx 1) -> M2 (Tx 1) -> M3 (Tx 1) -> M4 (Tx 2) 

Which methods of a session bean, with container-managed transaction 
demarcation, run in an unspecified transaction context? (Choose all that 
apply.) 

M A. ejbActivate() 

^ B. ejbPassivate() 

^ C. Business method marked 'NotSupported^ 

^ D. e jbRemove () 

口 E. Business method marked ‘RequiresNew’ 

If a session bean’s business method invokes 

E JBContext . setRollbackOnly ( ) , which transaction attribute settings can 
cause the container to throw the java. lang. IllegalStateException? 

(Choose all that apply.) 

^ A. NotSupported 
Q B. Required 

C. Supports 

D. Re quire sNew 

E. Mandatory 

F. Never 


( s ? e 6： 识廣 ，讣) 


( s _: 如- 别) 


4 

□ 

□ 
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Which method can be called successfully by a bean using bean-managed 
transaction demarcation? 

^ A. getUserTransaction() 

□ B. afterBegin() } J\\tst ^ 

□ c . — 一 一一士 

Q D. getRollbackOnly ( )- -this is -for CMT \)tBv\s o^ly 




you are here ► 523 




10 exceptions In EJB 


♦ 


♦ When beans go bad ♦ 



Expect the unexpected. Despite your best efforts, things can go wrong. 
Terribly, tragically, wrong. You need to protect yourself. Others depend on you. You 
can’t let your entire program collapse, just because one bean in the family throws an 
exception. The application must go on. You can’t prevent tragedy, but you can prepare 
for it. You need to know what is and is not recoverable, and who is responsible when a 
problem occurs. Should the Bean Provider tell the Container there’s still hope? Should 
the Container tell the client to try again? Or should the Container cut its losses, kill the 
bean, and let the SysAdmin sort it out later... 


this is a new chapter 
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SxcefitcoH^ 




12.1 Identify correct and incorrect statements 
or examples about exception handling in 
EJB. 


12.2 Given a list of responsibilities related to 
exceptions, identify those which are the 
Bean Provider’s, and those which are 
the responsibility of the Container. Be 
prepared to recognize responsibilities for 
which neither the bean or Container are 
responsible. 


12.3 Identify correct and incorrect statements or 
& examples about application exceptions and 
. system exceptions in entity beans, session 
1 名■衅 beans, and message-driven beans. 

Given a particular method condition, identify 
the following: whether an exception will be 
thrown, the type of exception thrown, the 
Container’s action, and the client’s view. 
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You have to know that application exceptions are 
things the client expects, and might recover from, 
while system exceptions are for things the client can’t 
recover from. You need to know the five standard 
EJB application exceptions, and all of the common 
system exceptions. You have to know exactly how 
the Container behaves when the bean throws an 
application exception vs. a system exception, and 
you have to know the difference between exceptions 
for local clients and exceptions for remote clients. 

You need to know that if the bean throws an applica¬ 
tion exception, the Container does not automatically 
rollback the transaction, and that the Container gives 
the exception to the client exactly as the bean threw it. 
With system exceptions, however, the Container al¬ 
ways rolls back the transaction, and gives the excep¬ 
tion to a remote client as a RemoteException, and 
to a local client as an EJBException. You’ll need to 
know that if a bean wants to rollback a transaction, as 
part of an application exception, the bean must call 
setRollbackOnly(), since the rollback won’t happen au¬ 
tomatically. You need to know that the Container will 
log system exceptions but not application exceptions, 
and that the Container will kill any bean that raises a 
system exception. 

If you’re going to answer these questions correctly, 
you have to know bean details from previous chapters. 
For example, you have to know that a message-driven 
bean doesn’t have a client view (i.e. client interfaces) 
so a message-driven bean can’t declare or throw any 
application exceptions. And you have to know, for ex¬ 
ample, that a bean will get an NlegalStateException if it 
tries to call methods on its context from places where 
those operations aren’t allowed. 






exceptions in JB 


What caw go wrowg? 


(?) In the Bean 

■ The business logic in a method realizes that it cannot do its job because of a problem 
the client expects. For example, a banking bean can’t do a balance transfer, because 
the ‘transfer from’ account doesn’t have any money! 

■ The bean catches a checked exception while running business logic. For example, the 
bean fails to get a JDBC connection, ora JNDI lookup throws a NamingException to 
the bean. This is a problem that the bean expects, but the client doesn’t. 

■ A method in the bean (or a method the bean calls) throws a runtime exception (like 
NullPointerException) that the bean doesn’t catch, and the client doesn’t expect. 


② In the Container 

■ The Container can’t complete an operation for which its responsible, such as updating the 
state of an entity bean in the database, that causes a problem the client expects. 

■ The Container catches a checked exception thrown by the bean, that the client expects. 

■ A Container catches a runtime exception thrown by the bean, or by some other object the 
Container interacts with. This is a problem that the client does not expect. 


(D In the RMI subsystem ，or some other part of the 
communication path between client and container. 

■ The EJB object throws a runtime exception before it communicates with the client 
about the result of a client’s business method call to the bean. 

■ The RMI subsystem can’t communicate with the client. 

■ The client stub throws a runtime exception, ora RemoteException while trying to send 
a method call, or receive a return value. 
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Java exceptions 


Remember ： Java exceptions can be checked or unchecked 



We know that you remember all of this, but just so we’re all speaking the same language 
here — Java has both checked and unchecked exceptions. Checked as in compiler-checked. If you 
call a method that declares a throws clause with a checked exception, you must reassure the 
compiler that you know all about this potential problem, and you’re ready to take the risk. It’s 
the handle or declare rule. You either wrap the risky method call in a try/catch, or you declare 
that you, too, throw the exception. 

Remember, declaring an exception means ducking it — letting someone else in the call stack 
deal with it. Declaring an exception is like saying, “I don’t want to catch this exception, 
because I think someone else can do a better job of handling it (or someone else should be 
handling it). 

If you handle an exception and exit the catch block, it should make no difference whether the 
exception occurred or not. If it does matter, then you aren’t handling the exception correctly, 
and you probably should have ducked it instead. 

Runtime exceptions are unchecked (they matter only at runtime, not compile time). You can 
declare them, catch them, and throw them in code any way that you like, but the compiler 
won’t care. But if your code causes a runtime exception, the call stack/thread of execution 
you’re running in dies. If that’s the last non-daemon thread in your program, your whole 
program shuts down. 
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exceptions in JB 


Ifs all about expectations... 

Exception handling in EJB (or Java in general) 
centers on expectations. You hope that everything 
works correctly. You hope that you don’t get a runtime 
exception. But you take risks. So you expect that some 
things will go wrong. The key is in knowing what those 
things are, and what you can do to recover. 

Most of the time, the things that can go wrong are 
pretty obvious. You do aJNDI lookup, but the object 
isn’t there. You try to connect to a naming service, and 
can’t. You try to connect to the database and can’t. 

You try to create a new entity bean, and the insert 
fails because you have a duplicate primary key. And 
for each of those, you can write a catch block that 
nows how to deal with the specific problem you have. 
Can’t connect to the naming service? Maybe you have 
a second naming service to try. Can’t connect to the 
database? Maybe you can try using a local cache for 
now, until you can re-establish your connection. Can’t 
do the insert? Try again, using a different primary key. 

When you provide a catch block for a risky method 
call, you’re saying that you expect something specific 
might go wrong. Almost every exception for which you 
provide a catch block is an exception that you expect. 
So you might, for example, expect a NamingException 
or a FinderException or a CreateException. 


Wr^ping a risty metkod call in a 
try/catcK tells the compiler (and 
your design) that you expect ikat 
certain iliings mi^rt wrong. 

You hope that everything worts 
correctly, hut you can’t guarantee 
it so you Kave a list of catcK 
blocks, for toigs you e^ect 

MIGHT wrong... 


Breathing in... I let go of my 
attachments. Breathing out... I let go of 
my expectations. Breathing in... I let go 
of my attachments. Breathing out... I let go of 
my expectation that my boss will give me the 
recognition I deserve. Breathing in... I let go of 
my need to back my SUV over my boss 
again and again and... 



i*t is ih all of li-fc, 
y/'rtii -the 

key b> i^appmess is -to 


you are here ► 


529 





exception pathways 


Exception pathways 


① Bean throws something the client expects 

、'Hey client, something you ''Tell client that something 

expect has happened” she expects has happenecT 



/« m 


② Bean throws something the client does NOT expect 


''Sorry client, but something ''Tell client that something 

terrible has happened” terrible has happened” 



③ Container throws something the client expects 


u Hey client, something you 
expect has happened. 



\s 



530 Chapter 10 




















exceptions in JB 


④ Container throws something the client does NOT expect 


''Sorry client, but something 
terrible has happened” 



docs^i 

6a»ASC *tV>c ^v-oklcw. 



⑤ The stub throws something the client expects 


''Something you expect 
has happened” 



r 





⑥ The stub throws something the client does NOT expect 

''Something terrible 
has happened” 


J 


no ^voklcws w'rtK 
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Application and System exceptions 


Iw EJR exceptions come iw two flavors: 
application and system 


Application exceptions are things the client expects, which means the client has to 
handle them one way or another. This means that application exceptions are 
declared in the interfaces exposed to the client, and the client uses a try/catch 
when she calls the method. Since the client can catch the expected exception, the 
client might be able to recover and keep going. Application exceptions include 
things like CreateException (maybe the client-supplied arguments weren’t valid), or 
AccountBalanceException (perhaps the client can try a different account with the 
next call), or ObjectNotFoundException (that entity is no longer in the database). 
Application exceptions include all checked exceptions thrown by a bean or a Container, 
except java.rmi.RemoteException. Although RemoteException is checked, and the 
client catches it, as far as the client is concerned, whatever caused the RemoteException 
on the server was unexpected. 

System exceptions are for things the client does not expect and/or can’t recover from. This 
could be virtually any runtime exception that happens on the server (from the bean 
or the Container or any other object on the server), or even in the client’s local stub 
object. System exceptions are things the client really can’t recover from, either because 
they’re not recoverable (like a failure in the database or a NullPointerException) or 
because the client doesn’t have enough information to know what to do (like with a 
RemoteException which — even though it is a checked exception the client catches — tells 
the client only that something unexpectedly bad happened on the server.) 



j Gotta love application 
exceptions... I can 
recover from this if I put 
in a different value for the 
argument to the create() 

. method... 

^^ 〆 


o 
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exceptions in JB 


With aw Application Exccptiow, the Cowtaiwcrwill... 

① send it back to the client EXACTLY as it was thrown 



② NOT set the transaction to rollback 



③ spare the bean’s life 
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System exceptions 


With a System Exccptiow, the Cowtaiwcrwill... 


① send it back to a Remote client as a RemoteException, 
or to a local client as an EJBException 



② always cause a transaction rollback 



③ kiM the bean，and log the exception 


This bean is history. Who 
KNOWS what state its variables 
are in now... I have to assume ifs 
corrupt, and kill it. I'll log it for 
the sys admin. 






铷 s Itrf ® 巧七 

and ^ W ^loaacd 


aavbay € 

⑼七、 切 

sfcll aVwc , 如 
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exceptions in JB 


Client recovery 


Transaction status 


Bean instance 


Logging 


Examples 


Compiler checking 
and other rules 


Application Exceptions 


System Exceptions 




transaction proceeds (unless automatic rollback 

bean calls setRollbackOnlyQ) 



instance lives 



instance dies 



NOT logged 



exception logged 


CreateException 

RemoveException 

FinderException 

Obj ectNotFoundException 

DuplicateKeyException 

AccountBalanceException 

BadQueryArgsException 

BookMappingException 

Exception 


RemoteException (remote client) 
EJBException (local client) 

工 llegalStateException 

TransactionRequiredException 

NoSuchObjectException 

ArraylndexOutOfBoundsException 

NullPointerException 

RuntimeException 


All application exceptions MUST 
be checked exceptions, and must 
NOT extend RemoteException 


The only system exception that is 
checked is RemoteException. All 
others are a RuntimeException (or 
one of its subclasses) 
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Application exceptions 


That can t be right... if 
I throw an application 
exception, I think there s a darn 
good chance that I do NOT want 
the transaction to commit... 






What, if anything, can you do if you know you 
want to throw an application exception to the 
client, but you do NOT want the transaction to 
commit? 


Think about that for a moment. 

We’ll take a look at this scenario in a few pages. 
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Warwiwg! RemoteException is checked, 
but wot expected! 


Normally when we think of expected vs. unexpected 
exceptions, we map it to checked vs. unchecked exceptions. A 
FilelOException is expected. A NullPointerException is not. 

Any direct subclass of Exception is expected. A subclass of 
RuntimeException is not. A checked exception must be handled. 
An unchecked exception usually won’t be. 

But there’s one big exception to the whole exceptions and 
expectations thing ― java. rmi.RemoteException. 

RemoteException is a checked exception, of course, so the client 
is forced to acknowledge a RemoteException by handling it with 
a try/catch. But unlike the other checked exceptions a client 
sees in a bean’s interface, RemoteException is still considered 
unexpected. OK, not exactly unexpected... but unexpected. 

From the client’s point of view, think of RemoteException a kind 
of runtime exception on the remote part of the application. 
Because that’s often what it means. A NullPointerException 
on the server means a RemoteException to the client. A 
DivideByZeroException on the server means a RemoteException 
to the client. A ClassCastException on the server means a 
RemoteException to the client. Those are all unchecked 
exceptions on the server, but they propagate back to the client 
as a checked RemoteException. In other words, the client has to 
expect that the server can throw something unexpected. 

Does this mean that every RemoteException on the client was 
originally triggered by a bean getting a runtime exception? No. 

A bean might, for example, catch a checked exception as part of 
its business logic, and then realize it can’t recover. At that point, 
the bean turns what was originally a checked exception (from 
the bean’s perspective) to an unchecked (system) exception by 
wrapping and rethrowing it as an EJBException, which ultimately 
shows up as a RemoteException on the remote client. 


^plication exceptions are 
always compiler - eliecked 
exceptions, except for 

ReinoteException. 

TTiint of RemoteException 
as “a rimtiine exception on 
ihe server”, even ^lou^k 
RemoteException is a 
cKected exception to ilie 
client. 

In other words, a remote 
client must EXPECT 

server can ihrow 
someteig TMiXPECTED. 


In fact, the client can get a RemoteException even without the 
server. A stub, for example, might throw a RemoteException 
because it can’t even reach the server. The key here is to think of 
application exceptions as checked exceptions that the client must 
acknowledge and might recover from, and system exceptions as all 
other exceptions, including RemoteException (and its subclasses). 
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declaring exceptions 


A Remote entity bean home interface declares application 
exceptions and one system exception (RemoteException) 


package headfirst; 


import javax.ejb.*; 

import java.rmi.RemoteException; 

import j ava.util.Collection; 

public interface CustomerHome extends EJBHome 


、。於 



7^ 


public Customer create(String last, String first) throws CreateException, RemoteException; 


public Customer findByPrimaryKey(String key) throws FinderException, RemoteException; 


public Collection findByCity(String city) throws FinderException, RemoteException; 



sor^c-thihg -the dlichi 


appkatioh CXdcp-tioh) 


somctWm^ 


Ajocal entity bean home interface declares only 
application exceptions 


package headfirst; 

import j avax.ejb.*; 

import j ava.util.Collection; 

public interface CustomerHomeLocal extends EJBLocalHome { 


cx ^p£ioh 



public Customer create(String last, String first) throws CreateException; 
public Customer findByPrimaryKey(String key) throws FinderException; 
public Collection findByCity(String city) throws FinderException; 
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RemoteException goes to remote clients 
EJPExceptiow goes to local clients 

When something unexpected happens on the server, the Container 
tells the client by throwing either a RemoteException or an 
EJBException. 

RemoteException is for remote clients only, and even though it is a 
checked exception, it’s telling the client that something unexpected 
happened. Something from which the client can’t recover. 

EJBException is for local clients only, and it’s unchecked. In other 
words, EJBException is a subclass of RuntimeException. To the 
client, getting an EJBException isn’t much different from getting, 
say, an ArraylndexOutOfBoundsException. It means something 
unexpected went wrong, and there’s nothing you can do to 
recover. The only difference is that the client does have to catch the 
RemoteException, but once he catches it, the client usually won’t 
be able to tell what happened (at least not in any recoverable way). 


犧 en someteig 
unexpected on 

ilie server, a local client 
gets a RuntinieException 
(EJBException) hit 
a remote client gets 
a compiler-cKecked 
RemoteException 


Remote client 




server heap 
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question on exceptions 



In the picture, you show the client 
thinking〆] have no idea what happened” 
when she gets a RemoteException. But when I 
get a RemoteException in my shell terminal, it 
usually tells me what happened with a message 
■ike,"A NullPointerException occurred on the 
server” or something like that... 

A- 

And at runtime that helps you how? Sure, it 
helps you a TON at development and testing time, 
but when your application is actually running, 
your client code probably isn’t going to parse 
the stack trace. When we say that the client 
has no idea what happened, we mean that the 
client wasn’t able to catch something specific — 
something recoverable. 

Contrast that with something like 
CreateException, where the client can catch the 
exception, and from the catch block try the create 
again, possibly with different arguments. 


checked vs. unchecked- 

And in fact, from the clienfs perspecf/Ve^^^^ 

士:。 

TJcLZeption... b ut one that t h e bean knew H 

couldn’t recover from.) 
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exceptions in JB 


Pean Provider's responsibilities 

① If your business logic catches (or creates) an application 

exception, throw it to the Container as the application exception 


In bean code, if you catch an application exception thrown by other code (or you create 
the exception as part of your business logic), throw it to the Container exactly as-is. For 


example, if your bean code gets a FinderException while trying to look up another bean 
(in other words, while calling a finder method on another bean’s home interface), give 


the FinderException to the Container exactly as you got it. That means either declaring it 
(ducking it and letting it propagate back down the stack to the Container) : 


public void someBusinessMethod() 
CustomerHome home = null; 
try { 


throws FinderException 


Java W 


InitialContext ic = new 工 nitialContext(); 
Object o = ic . lookup (''Customers"); 


home = (CustomerHome) PortableRemoteObject.narrow(o, CustomerHome.class); 
} catch(NamingException ne) { 

// deal with NamingException 


try { 

Customer cust = home .findByPrimaryKey ( 、 '42 〃）； 
// more stuff 

} catch(RemoteException re) { 

// deal with RemoteException 




Or catching it and rethrowing it as-as: 

public void someOtherBusinessMethod() 
CustomerHome home = null; 


throws 



FinderException { 


sWl V^avc ^ 

\-t, <>( ^OVAVSC 


try { 

工 nitialContext ic = new 工 nitialContext(); 

Object o = ic . lookup (''Customers ’’）； 

home = (CustomerHome) PortableRemoteObject.narrow(o, CustomerHome.class); 
} catch(NamingException ne) { 

// deal with naming exception 


try 


Customer cust = home .findByPrimaryKey ( 、 '42〃) 
// more stuff 

catch(RemoteException re) { 

// deal with it 
catch(FinderException fe) { 
if ( ! recoverable()) { 

throw fe; 

} else { //other stuff} 


Wc 


L \( yjc 
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Bean Provider and exceptions 


Pean Provider's responsibilities 


(2) If you catch an application exception, and find that you 

can’t continue the transaction，call setRollbackOnly() before 
throwing the exception to the Container. — 

Remember, the Container won’t rollback a transaction just because there’s an application 
exception. With an application exception, the Container assumes that the whole thing 
might be recoverable, and that the transaction can continue. Unless you find out, in 
your business logic, that committing would be a Really Bad Idea (it often is). What’s your 
option? Force the Container to rollback the transaction using setRollbackOnly() on your 
EJBContext (for a CMT bean) or on your UserTransaction (for a BMT bean). 

public void someOtherBusinessMethod () throws FinderException { 


CustomerHome home = null; 
try { 

InitialContext ic = new InitialContext(); 

Object o = ic. lookup (''Customers"); 

home = (CustomerHome) PortableRemoteObj ect.narrow(o, CustomerHome.class); 
} catch (NamingException ne) { 


// deal with naming exception 


try { 

Customer cust = home .findByPrimaryKey ( 、 '42 〃）； 
// more stuff 

} catch(RemoteException re) { 

// deal with it 


catch (FinderException fe) { 


if ( ! recoverable()) { 

context.setRollbackOnly() 
throw fe; 


• 4 ^^ 



} else { //other stuff} 
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Peaw Provider's responsibilities 

(D If your business logic catches an exception the client is not 
expecting (in other words，not declared in your client view) 
wrap it and rethrow it as an EJBException. 


How much should the client know about your internal behavior? Little or nothing, right? 
For example, is it any of the client’s business that you’re using JDBC to get your work done? 
And that you might, as part of your business logic, catch an SQLException? Throwing an 
EJBException is the programmer’s way of telling the Container, “I’ve lost control.” 


Can you say,、、too much 
information?" I REALLY didn’t 
need to know that about you. Um, 
in the future, I suggest that 
you do NOT expose your private 
problems to the world... 



Legal，but a bad idea: 

public interface BadService extend EJBLocalObject { 
public void someMethod() throws SQLException; 

} 广 

Po Vou \rcall7 iWmk % 
should 

public class BadServiceBean implements SessionBean { 
public void someMethod() throws SQLException { 

// do stuff that might cause an SQLException 

} 

// other bean methods 


The way you SHOULD do it: 

public interface GoodService extend EJBLocalObj ect { 
public void someMethod(); 


public class GoodServiceBean implements SessionBean { 


public void someMethod() 
try { 

// do stuff 

} catch (SQLException se) { 

// if we can't recover 
throw new EJBException(se); 


is a 

d 。把 ㈣ 口. 
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Pean Provider's responsibilities 


(4) If your business logic encounters a runtime exception ， 
let it propagate to the Container. Don’t try to catch it! 

Just don’t do it. Don’t use a try/catch to catch, say, Exception. That would 
mean you’d catch everything, and the worst thing you can do is to eat 
runtime exceptions without letting them pass back up to the Container. 

If you do need to catch a runtime exception, but then find that you can’t 
recover, you can simply throw it as-is. But whatever you do, don’t do this: 



(5) If your business logic generates an application 

exception，you must have declared the exception in 
both your client interface AND your bean class. 

Remember, just because you declare an exception in an interface doesn’t 
mean you have to declare the exception in your implementation of the 
method. That’s true regardless of whether you implement the method in 
the formal Java way (because your class says, “extends Thislnterface”）. But if 
there’s a chance that you’ll throw an application exception, either because 
you have a try/catch in your code, or because your own business logic can 


create one, you must declare the exception in your bean class. 



public void withdraw(double d) throws AccountBalanceException { 


if ( (balance - d) < 0) { 

throw new AccountBalanceException(overdrawnMsg); 



} else { 

balance d; 


public abstract void withdraw(double d) throws AccountBalanceException; 
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Pean Provider's responsibilities 


⑥ If you create your own application exceptions, they must extend 
(directly or indirectly) Exception, but not RuntimeException or 
RemoteException 


Although you’re encouraged to use, or extend, the standard EJB exceptions (we’ll get to 
those in a minute), when your design calls for your own custom exceptions, you must make 
them checked exceptions. That means they must extend java.lang.Exception (or one of its 
subclasses) as long as it does not extend java.lang.RuntimeException. The other restriction 
is that application exceptions must not extend java.rmi.RemoteException (directly or 
indirectly). Remember, an application exception is any checked exception declared in the 
client view, except RemoteException. 


public void withdraw(double d) throws AccountBalanceException { 
if ( (balance - d) < 0) { 

throw new AccountBalanceException(overdrawnMsg); 

} else {balance -= d;} 


class AccountBalanceException extends Exception { 
AccountBalanceException(String s) { 

super(s); 

} 

} 

^JiereiSireriP 

Dumb Questions 


I just realized something... the container 
callbacks declared in the SessionBean and EntityBean 
interfaces don’t declare checked exceptions, right? So, 
doesn’t this mean that you can’t throw an application 
exception from, say, ejbActivateO? 

A- 

That’s right! You can throw only unchecked 
exceptions from a container callback that is not part of 
your client view. This is just plain old Java...you can’t 
throw a checked exception from a method that doesn’t 
declare the exception, and since those interfaces don’t 
declare any checked exceptions that you can use, you’re 
stuck with runtime exceptions. The only thing you 
should throw from one of the container callbacks of 
SessionBean, EntityBean, or MessageDrivenBean, is an 
EJBException. 


You said the interfaces don’t declare any 
checked exceptions THAT YOU CAN USE. What does 
that mean? What’s an example of a declared checked 
exception that you can’t use? 

A- 

Jr \* If you go to the J2EE API (we’ll wait, while you do 
that... still waiting... waiting... waiting), you can see that 
all of the methods declare a RemoteException! Yes, a Big 
Fat Checked exception. (They also declare EJBException, 
as a nice gesture, but not a requirement since 
EJBException is a subclass of RuntimeException). Does 
this mean you can throw a RemoteException yourself? 
Like, if you caught one while your bean is being a client 
to another bean, for example? NO! NO! A 1024 times NO! 

In the days of steam-driven containers, the EJB 1.0 spec 
allowed you to throw RemoteExceptions, from your 
bean.Those days are over, and EJB 2.0 doesn’’t allow it. 
So unless you’re a poor soul tasked with legacy bean 
maintenance, you should avert your gaze when you 
look at the API docs, and pretend you never saw that 
RemoteException... 
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The Container and exceptions 


The Cowtaiwcr's responsibilities 

① If the bean throws an application exception, send it back to 
the client EXACTLY as it was thrown，and do NOT rollback the 
transaction. 

If the bean throws a CreateException, send that exception to the client. If the bean 
throws a FinderException, send that exception to the client. If the bean throws an 
AccountBalanceException, send that exception to the client. 

It makes no difference whether the exception is one of the standard EJB exceptions 
from the java.ejb package, or one that the Bean Provider defined. 



I was 
ready for an 
Account Balance 
exception 


AccountBalanceException 


AccountBalanceException 


② If the bean throws a system exception (including EJBException 
or any runtime exception) 

■ Throw a RemoteException if the client is Remote 

■ Throw an EJBException if the client is local 

■ Log the exception 

■ Rollback the transaction 

■ Discard the bean instance (assume it’s toast) 



EJBException 


Well that sucks. I 
got a RuntimeException... 


NullPointerException 


local client 


546 Chapter 10 
















exceptions in JB 




Think about the client for a moment. If the cli¬ 
ent gets a RemoteException, does the client 
know for certain that the business method 
completed? 

Does the client know for certain that the 
transaction was rolled back? 

Is there any way the client might be able to 
find out? 

What if the client is another bean? 



From the list of possible options, select what 
you, as a Bean Provider, should do in each 
of the following scenarios. Assume that they 
all take place within a business method of a 
session bean. 

Options (you may use an option more than once) 

A. Throw an EJBException 

B. Throw a RemoteException 

C. Invoke setRollbackOnlyf) 

D. Allow the exception to propagate (in 
other words, duck it). 


r t . There，s nothing on the exam 

a bout non 

for coping with transaction failures, 

\ But as a developer, ② ^ : 

•: happen on the client s,d J ^ transaction succeeded. •: 

: whi ch you donUnow \ 

\ If your client is a bean, The J2 EE client 

: application, you're in ^°° t Q f ' the transaction. But a 
\ can usually find out e other me chanism, or at 

'' non-J2EE dien = : e tha t if he attempts the same 
: least a way to g^rante 咖雄 succeeded (but he 
: transaction aga/n,a V subS equent) 

•: doesn’t know), that i\/hen you have an 

: attempt ^toause /f attem _ after 

: operation that wont syour operation is 

: its a / re f y f su ==；$ 二邮 // y 二 欣 ㈣ esound / 

\ Tt P Z it Zt b e critics，to t,e integrity — 


Scenarios 

You catch a checked exception in your 
ejbActivate method. The method is not in 
a transaction. 

A DivideByZero exception occurs as your 
business logic is running. You do not 
have a try/catch for this. 

You throw a CreateException from your 
ejbCreatef) method, and you realize that 
you probably cannot safely complete 
your transaction. 

You catch a checked exception in a 
business method，and realize that your 
bean is probably corrupt 
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Application exceptions 


The five standard EJP application exceptions 


The javax.ejb package has five standard application exceptions used by the EJB container, but 
you can use them as well, either directly or as superclasses to your own custom exceptions. 


Exception 


java.lang package 



CreateException 



FinderException 


DuplicateKeyException 




ObjectNotFoundException 


javax.ejb package 


① CreateException 

The Container throws this from, you guessed it, a create method, if something 
goes wrong during creation. This includes scenarios in which the bean code throws 
CreateException itself, while running a create method. (Although if the bean’s gonna 
throw it, the bean’s gotta declare it in the bean class, not just the home interface) 

② DuplicateKeyException 

The Container throws this to the client from an entity bean create method (see how it’s a 
subclass of CreateException?) if the business logic related to the create asks the Container to 
insert a new entity using a primary key that has already been assigned to another entity. 

③ FinderException 

The Container throws this to the client from an entity bean’s finder method, to tell the 
client that something went wrong during the finder. The bean might have thrown it (BMP 
beans only) ， but for CMP beans, only the Container can throw this method. 

④ ObjectNotFoundException 

The Container throws this to the client ONLY during single-entity finder methods, when 
there’s no entity in the database matching the primary key parameter of the finder method. 

⑤ RemoveException 

The Container throws this to the client from a session or entity bean when something 
goes wrong in a remove method. But... the bean provider can throw this exception if, for 
example, he doesn’t want to let clients remove entity beans. 
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The five standard application exceptions from the 
clicwfs poiwt of view 


Two of the five are more specific — DuplicateKeyException and 
ObjectNotFoundException. If the client gets an ObjectNotFoundException, the 
client has more information than if he gets a more abstract FinderException. And if 
the client gets a DuplicateKeyException, he knows a lot more about what went wrong 
than if he gets a generic CreateException. 

CreateException 

The client does not know for certain whether the bean was 
actually created. The Container might have had a problem after 
the transaction committed. 

DuplicateKeyException 

If the client catches a DuplicateKeyException, she can be 
100% certain that the bean was not created. 




FinderException 

The client does not know whether a matching entity (or 
entities, for multiple-entity finders) exists in the database. 
The Container might throw a FinderException because of 
something that went wrong before it was able to look in the 
datbase. 



ObjectNotFoundException 

If the client catches an ObjectNotFoundException, she can 
be 100% certain that there was no match for this primary key 
in the database. Remember, ObjectNotFoundException is 
for single-entity finders only, so a client will never get this for 
a multi-entity finder. 



RemoveException 

The client does not know for certain whether the bean was 
actually removed. The bean provider might simply have 
rejected the client’s request, as in, 'You can ask all day long, 
but there is no WAY that I’m going to remove that entity from 
the database.” Or the entity might have been removed from the 
database, but then something else went wrong that triggered 
the RemoveException. 
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Application exceptions 


^tliereiareJiP 

Dumb Questions 


Stateless session bean 
clients will NEVER get a 

RemoveException! 

lf pZ 0U Se l a scenari0 where the client gets a 
RemoveException, you can rule out stateless 

Z s = eans . r 嫩* 社屬 
: bean l rem ova!is NEVER tied to a client so 
\ h h e s n ^ bod Y to give the exception to. You can 

hrowa RemoveException from your eibRe 

=0_ Od ， buttheclient J n llZ ei tif 

the bean ls a stateless session bean. 


The client might 
NOT get the 
most specific 
exception 

Don't count on ALWAYS getting the 
most specific exception on the client. 

The Container might not, according 
to the spec, send the client a 
DuplicateKeyException even if that is 

the problem. 

What does this mean to the clients 
If the client’s code has a catch 
for both a CreateException and a 
DuplicateKeyException, the client 
can't be completely certain that if 
she catches a CreateException, the 
problem is NOT a duplicate key issue. 
This would be bad if, for example, he 
client code just kept trying to create(), 
sending in the same key thinking, I 

didn’t get a DuplicateKeyException, so 

I know THAT ca^t be the problem... 

If you get a CreateException 
on the client, and NOT a 

DuplicateKeyException, you wont 
know for certain that the key is oK. Its 
up to the Container whether it gives 
you the more specific exception. 


If a RemoveException makes no sense 
for a stateless session bean, why are you 
allowed to throw it (assuming you declare it 
on your bean's removeO method)? 


A ： 


Remember, there’s nothing in the bean 
class that can tell you whether the bean is 
definitely state/ess. You can tell if a bean is 
stateful, of course, because any bean with 
overloaded creates (or it’s only create has args) 
must be stateful. But even if a session bean has 
only a single no-arg create method,you still 
don’t know whether that bean is going to be 
marked stateless or stateful at deploytime. 

This would all be different if there were a 
separate interface for StatelessSessionBean 
and StatefulSessionBean, that your bean had 
to implement (instead of just SessionBean), but 
that’s not how it works. 

If the Bean Provider doesn’t want to let 
entity bean clients remove a bean, why does 
he have a remove method? 


A ： 


Aren’t you forgetting something obvious 
here? Where do the removeO methods live? 

How are they exposed to the client? That’s right. 
In the client interfaces. Remember, there are 
three removeO methods available to a remote 
entity bean client (the no-arg in the EJBObject 
interface, and the remove that takes a key and 
the remove that takes a handle in the EJBHome 
interface). A local entity bean client has two 
remove methods — the one in EJBObject, and 
the one in the home that takes a primary key. So 
there’s nothing you can do to hide the removeO 
methods from a client, but if you don’t support 
it from your bean, throw a RemoveException 
from your bean’s ejbRemoveO method, and the 
Container won’t go through with the remove. 
This is your way of telling the Container,"Don’t 
do it!! I don’t care what the client says, don’t you 
dare go through with the remove!” 
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Common system exceptions 

Besides the standard application exceptions for EJB，there are several 
important system exceptions. A few (including EJBException) are part of 
the J2EE API, but two of the most likely system exceptions in EJB include 
java.rmi.NoSuchObjectException and java.lang.IllegalStateException. 


Local clients and 
beans will get these 
(unchecked) 


javax.ejb package 


java.lang package 

l/ 



NoSuchObjectLocalException 


NoSuchEntityException 


TransactionRequiredLocalException TransactionRolledbackLocalException 


Only Remote clients will get these (checked) 


java.rmi package — > 


RemoteException 



TransactionRolledbackException 



javax.ejb package 
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System exceptions 


Common system exceptions 

① HlegalStateExceptiori 

The Container throws this to a bean if the bean calls a method on its context that isn’t 
allowed at that time. For example, a session bean can’t ask its context for a reference to 
its EJB object while in the setSessionContext() method. It’s too early. A bean can also 
get an IllegalStateException if it calls a transaction method like setRollbackOnly() or 
getRollbackOnly(), when there’s no transaction! 

② EJBException 

The bean throws this to tell the Container a system exception has occurred (which forces the 
Container to rollback the transaction, log the exception, kill the bean, and give a local client 
the EJBException and a remote client a RemoteException). But the Container can also throw 
this for a variety of other reasons we’ll look at in a minute. 

③ NoSuchObjectLocalException 

This exception is kind of a local companion to java.rmi.NoSuchObjectException. The 
Container throws it to the client when the client invokes a method on a local home or 
component interface, but there’s no underlying bean to support the object. This can 
happen, for example, if the bean has already been removed (either through a previous client 
call to remove(), or because the Container killed the bean due to an exception, stateful bean 
timeout, or to reduce the size of the pool). 

④ NoSuchEntityException 

You probably won’t see or use this exception much, especially with CMP, but it’s for you to 
throw from your bean code when you want to tell the Container that the entity you’re trying to 
access is no longer in the database (perhaps because it was removed by an admin application). 

(5) TransactionRequiredLocalException / TransactionRequiredException 

The Container throws this to the caller when the called method has a transaction attribute 
of mandatory, but there’s no transaction context coming in with the call. In other words, it’s 
mandatory that the caller invokes the method within an existing transaction, and if there isn’t 
one, the appropriate TransactionRequired exception is thrown (depending on whether the 
client is local or remote) 

(§) TransactionRolledbackException / TransactionRolledbackLocalException 

The Container throws this to the caller when the Container can’t commit the transaction, and the 
caller invoked the method within an existing transaction context. But the Container will not throw 
this exception if the failure to commit is because the bean explicitly called the setRollbackOnly() 
method. In that case, the Container will rollback the transaction and pass the business method 
result back to the client (unless the bean also throws an application exception). 
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YouVe kidding, right? 

How am I supposed to remember 
the difference between, say, 
NoSuchObject and ObjectNotFound 
exceptions? I wonder what genius came 
up with such clear, easy to distinguish 
names. On, and let me guess— 
theyVe on the exam... right? 




java.rmi. NoSuchObjectException 


〆 


愐 o,W KOT - 

Remote 





ws added io BJB 

local ihtcv-fadcs 


xi h L Z a H 

K the dlichx has ihV^lid 
javax.ejb.NoSuchObjectLocalException BJB object ^cfev'c^c 




javax.ejb.ObjectNotFoundException -tWis \s OKL-V ^ , n 

.e-bWs! le 一 ^ 切仏如 s) 

^ ^ Cd ^ d h ⑽松仏 . |S ,— 

javax.ejb.NoSuchEntityException you || probably hCV ^ i 

紀士 A 



OK, we agree. The names feel a little, 
shall we say, arbitrary. But remember, the 
NoSuchObjectException came first. It was 
designed for the scenario where the client has a 
stub to a Remote object, and for whatever reason 
the Remote object is no longer usable. Might have 
been a server crash. Might be that the service 
itself has been undeployed. Doesn’t matter. As 
far as the client’s concerned, the phone has been 
disconnected over at the server side. 


NoSuchObjectLocaZException was added when 
local client views were added in EJB 2.0. The 
concept is slightly different, because the local 
client is using not a stub, but a real Java object 
reference. But from the client’s perspective, 
it really doesn’t matter whether it’s local or 
Remote — a NoSuchObject<whatever> exception 
means you can’t use your EJB object reference to 
get to a bean! You have to go back through the 
home and start over. 
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confusingly-named exceptions 





ObjectNotFoundException is a FinderException 




Are you sure you 
looked everywhere? 
And you still didn’t find 
any record of Paul 
Wheaton? 


I tried to find him, but an 
exotic dancer named Paul 
Wheaton was Not Found 
anywhere in the records. Maybe if 
we upgraded to a database that’s in 
color I could actually get something 
done around here... 


I'm sorry, but there's No Such 
person here. Yes, I realize that 
this is how you contacted him 
in the past. But trust me, honey. 
He's been removed. I put his body 
through the wood chipper not 
two days ago... 


NoSuchObectException is when the client still has 
a stub to a Remote object, but the object has been 
removed (or is no longer valid for any other reason.) 


NoSuchObjectLoca/Exception is when the local client 
has a reference to an EJB object for a bean that’s been 
removed (or is no longer valid for any other reason). 
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BULLET POINT 



■ Exceptions in Java can be checked or unchecked. 
Checked exceptions extend java.lang.Exception, 
but not java.lang.RuntimeException 

■ Exceptions in EJB can be thrown from the bean to 
the Container, and from the Container to the bean. 

■ EJB exceptions come in two types: application and 
system. 

■ Application exceptions are checked exceptions that 
the client is expecting, and might be able to recover 
from. This includes all checked exceptions except 
java.rmi.RemoteException and its subclasses. 

■ System exceptions are all other exceptions, 
and include all runtime exceptions, plus 
RemoteException. 

■ For the client, a RemoteException can be treated 
as though a runtime exception (i.e. something 
unexpected) happened on the server. 

■ When the Container gets a system exception, it 
will rollback the transaction, log the exception, and 
throw away the bean. 

■ When the Container gets an application exception, 
it will send it to the client exactly as it was received. 
The transaction will not automatically rollback, and 
the bean’s life will be spared. 

■ The Bean Provider should throw application 
exceptions to the Container as-is, so that the 
Container can pass them on to the client. If the 
bean’s transaction is possibly corrupt, the Bean 
Provider should call setRollbackOnly() before 
throwing application exception, so that the 
Container will not commit the transaction. 


■ If the Bean Provider catches an exception from 
which the bean cannot recover, he should wrap 
and re-throw the exception as an EJBException (a 
runtime exception, so he didn’t need to declare it). 

■ There are five standard EJB application exceptions: 
CreateException, DuplicateKeyException 
(extends CreateException), FinderException, 
ObjectNotFoundException (extends 
FinderException), and RemoveException 

■ Common system exceptions include EJBException, 
HlegalStateException, TransactionRequiredLocalEx 
ception, and NoSuchObjectLocalException. 

■ ObjectNotFoundException is for when single¬ 
entity finder methods cannot find an entity in the 
persistent store, that matches the primary key 
argument to the finder method. 

■ NoSuchObjectException is an RMI exception for 
when a Remote client has a stub to a Remote 
object that’s been removed, or is invalid for some 
other reason. 

■ NoSuchObjectLocalException is a runtime 
exception for when a local client has a reference 
to an EJB object that’s no longer valid (most likely 
because the bean has already been removed). 
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Scenarios: what do you thiwk happcws? 

Technically, this section is like a big stealth Sharpen Your Pencil exercise. Only 
we just told you, so maybe not so stealthy. Sure, we could just tell you everything 
one fact after another... but you’ll have a much better chance at remembering 
it if you work it out for yourself. We summarize everything near the end of the 
chapter, but do NOT jump there now! Even if you’re someone who never does 
the exercises, do this scenario walk-through. You’ll think of us fondly when you’re 
holding your lovely lapel pin that you get from passing the certification exam. 

① A message-driven bean’s onMessage() method catches an application exception. 

Can it re-throw the application exception to the Container? 

(Hint: what does a Container usually do when it gets an application exception from a 
bean? Would the Container be able to do that in this scenario?) 

② A session bean using CMT has a method marked with the NotSupported transaction 
attribute. While the method is running, the bean calls setRollbackOnly() on its context. 
Will this cause an exception? What kind? 

(Hint: think about what setRollbackOnly() does, and what state the bean has to be in.) 

③ A message-driven bean, in the onMessage() method, calls getCallerPrincipal(). What 
happens? 

(Hint: what’s getCallerPrincipal() used for? Does that make sense here?) 


④ A session bean using CMT has a method marked with the Mandatory transaction 
attribute. The client calling the method is not in a transaction. What happens? 

(Hint: Think about the names of the common system exceptions. Is there one that 
makes sense here?) 

(s) A bean realizes it can't commit a transaction, but it doesn’t want the client to get an 
exception. What can the bean do? 


⑥ A bean wants the client to get an application exception, but the bean still wants the 
transaction to commit. What should the bean do? 
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贫考 rpen your pencil 


Scenarios 


Match the scenarios with the exception(s) that might 
occur with that scenario. Don’t turn the page!! The 
answers are just a page away. 


Transactions 


A CMT bean calls context. getilserTransaction (). 

Client calls remove() on a bean that’s already been removed. 

Client calls removef) on a stateful bean that is still in an open 
transaction. 

A session bean calls getPrimaryKey() on its context. 

A CMT bean calls getRollbackOnly(), from a method marked 
NotSupported. 

Client calls a method on a Remote CMT bean, and the 
method is marked Mandatory. The caller does not have a 
transaction context in place when the call comes in. 

A message-driven bean calls isCallerlnRole() on its context, 
from within the onMessage() method. 

Client calls the home remove method on the LOCAL home 
interface of a session bean 

A stateless session bean calls getCallerPrincipal() on its 
context, during the setSession Context method. 

Client Foo calls a method on a remote stateful bean, while 
that same bean is already executing a method for client Bar. 

Client calls getPrimaryKey() on the local component interface 
of a session bean. 


11lega I State Exception 

EJBException 

CreateException 

RemoveException 

ObjectNotFoundException 

NoSuch ObjectException 

RemoteException 

TransactionRequiredException 

NotSupportedException 

RuntimeException 

NoSuch ObjectLocalException 

DuplicateKeyException 

SystemException 

NoSuch Entity Exception 


A message-driven bean catches a NamingException, from 
which it can’t recover. Which exception (if any) can the bean 
throw to tell the Container? 


A session bean wants the Container to know that the 
transaction should be rolled back and the bean should be 
killed. 


Client calls findByPrimaryKey (“ 23”)，where there is no entity 
with a primary key of “23”. 


Although the bean is fine, the Container has a system 
exception it wants to throw to a local client. 
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Scenario Summary 


Transaction Scenarios 


ACMT bean calls context.getUserTransaction(). 

The bean gets an IHegalStateException. (Only BMT beans can get a 
UserTransaction) 


Client calls remove() on a stateful bean that is still in an open 
transaction. 

The client gets a RemoveException. You can’t remove a stateful bean 
while its in a transaction. (Which is just one of a gazillion reasons why it’s 
a Bad Idea to leave a transaction open across multiple client invocations. 
In other words, if you begin a BMT transaction in a method, you should 
end it in that method!) 


A CMT bean calls getRollbackOnly(), from a method marked 
NotSupported. 

The bean gets an IHegalStateException. You must be in a transaction 
when you call getRollbackOnlyQ or setRollbackOnly(). That means you 
can’t call them within a method marked NotSupported, Never, or Supports 
(session and entity beans) or NotSupported (message-driven beans — 
remember, message-driven beans can’t use Never or Supports, because 
they don’t make sense given that transactions can never propagate into a 
message-driven bean.) 


Client calls a method on a Remote CMT bean, and the method is 
marked Mandatory. The caller does not have a transaction context in 
place when the call comes in. 

The client gets a TransactionRequiredException (a local client would get 
TransactionRequiredLocalException). 

A session bean wants the Container to know that the transaction 
should be rolled back and the bean should be killed. 

The bean should throw an EJBException. The Container takes over 
and does its normal Container thing for system exceptions — rollback 
the transaction, log the exception, kill the bean, and throw a 
RemoteException to a Remote client or the EJBException to a local client. 
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Scenario Summary 


Client Scenarios 


Client calls remove() on a bean that’s already been removed. 

You might be tempted to say RemoveException, but that’s not it! Remember, 
remove() is just another method in the bean’s interface, and if you call it 
on a removed bean, you’ll get the same exception you’d see if you called 
any other business method on a removed bean — remote clients get 
RemoteException, and local clients get EJBException. 


Client calls the home remove method on the LOCAL home interface of 
a session bean. 

The client gets a RemoveException. Why? Because the only remove() 
method in a session bean’s local home is the one that takes a primary key, 
and that can never work. Remote clients would also get a RemoveException. 


Client Foo calls a method on a remote stateful bean, while that same 
bean is already executing a method for client Bar. 

Client Foo gets a RemoteException (if client Foo had been local, he’d get an 
EJBException). A session bean handle only one client at a time! 


Client calls getPrimaryKey() on the local component interface of a 
session bean. 

This is just like the one where the client calls remove() on a local bean’s 
home. The client gets an EJBException (if the client were local, he’d get a 
RemoteException). The point is? Session beans don’t have primary keys! 
Any method you call related to the primary key of a bean will fail if that bean 
is a session bean. 

Client calls findByPrimaryKey (“ 23”)，where there is no entity with a 
primary key of “23”. 

The client gets an ObjectNotFoundException, a subclass of FinderException. 


Although the bean is fine，the Container has a system exception it 
wants to throw to a local client. 

The client gets an EJBException. 




exception scenarios 


Scenario Summary 


Bean Scenarios 


A session bean calls getPrimaryKey() on its context. 

The bean gets an IHegalStateException. You know why. Session beans 
and primary keys don’t go together... 


A message-driven bean calls isCallerlnRole() on its context, from 
within the onMessage() method. 

Think about it Does a message-driven bean have a calling client (we 
don’t really count the Container as a ‘client’，although it is calling the 
bean’s methods). If there’s no client, then WHOSE security information 
would the bean get? The bean gets an HlegalStateException just for 
being clueless enough to even try. 


A stateless session bean calls getCallerPrincipal() on its context, 
during the setSessionContext method. 

The bean gets an HlegalStateException, because setSessionContext() 
is too early in the bean’s life to get client information. In fact，a 
stateless bean can get client security information ONLY while running 
a business method of the component interface. And even if the bean 
were stateFUL, it would still be too early for client information, although 
a stateful bean (but not stateless) could call getCallerPrincipal() and 
isCallerlnRoleQ from within ejbCreateQ. 


A message-driven bean catches a NamingException, from which 
it can’t recover. Which exception (if any) can the bean throw to 
tell the Container? 

The bean should throw an EJBException. Remember, message-driven 
beans don’t have clients. They don’t have client interfaces. So there’s 
no place to declare application exceptions. That means your bean 
can’t throw anything but system exceptions. The only exception the 
message-driven bean should ever throw is EJBException. It can never 
throw application exceptions, and it should let other system exceptions 
propagate to the Container. 
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Fill this chart in to describe the differences between 
remote and local clients. You’ll want to use this as a 
cheat sheet before the exam, so don’t screw it up. 


be 七 same 

(or both vcmo*tc dhd lo£>al 
dietrrts, bu*t v/C 


Remote clients 


How system exceptions in the 
bean are delivered to the client. 


The exception for when the client 
calls a method on a bean that’s 
been removed. 


The exception for when 
the client calls a method 
marked Mandatory, without a 
transaction context in place. 


The exception for when the client 
starts a transaction, and the 
Container has to roll it back. 


The exception for when the 
client calls getPrimaryKey() on 
the component interface of a 
session bean. 


The exception for when the client 
calls a method in a session bean 
and the bean is already executing 
a method for another client. 


The exception for when the client 
calls a remove() method on a 
stateful session bean that’s still in a 
transaction. 


Local clients 
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Deja vu? Yes, you’ve seen this. Near the beginning of 
this chapter. Except it was all filled in. Now it’s your turn. 
Bonus points if you use drawings along with your words. 


Application Exceptions 


System Exceptions 


Client recovery 


Transaction status 


Bean instance 


Logging 


Examples 


Compiler checking 
and other rules 
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Sxam 


What is true when an entity bean’s client receives ajavax.ejb.EJBException? 
(Choose all that apply.) 

口 A. The client must be remote. 

Q B. The client must be local. 

口 C. A client will never receive this exception. 

口 D. The client must handle or declare this exception. 

[I E. This exception can only occur if the client is in a transaction. 

Which scenario will cause ajava.rmi.NoSuchObjectException to be thrown? 
(Choose all that apply.) 

Q A. A remote client invokes a method on a stateful session bean which has 
been removed. 

口 B. A remote client invokes a method on an entity bean which has been 
removed. 

[I C. A remote client invokes a finder method with invalid arguments. 

Q D. The container invokes an ejbPassivate() method on a bean that is not 
ready to be serialized. 

Which is a subclass of java.lang.RuntimeException? (Choose all that apply.) 

口 A. javax. ejb. EJBException 
Q B. javax.ejb.RemoveException 

□ C. javax.ejb.CreateException 

口 D. javax.ejb.NoSuchEntityException 
口 E. java. rmi. RemoteException 

□ F. j avax. ejb. Ob j ectNo tFoundException 

□ G. java. rmi.NoSuchObjectException 
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coffee cram mock exam 


Which of the following are EJB 2.0 specification guidelines regarding system 
exceptions? (Choose all that apply.) 

Q A. Bean methods should catch RuntimeException exceptions. 

Q B. Bean methods should wrap unrecoverable checked exceptions in a 

j avax. ejb. EJBException exception. 

口 C. For remote clients, bean methods should wrap unrecoverable checked 
exceptions in a java. rmi.RemoteException. 

口 D. If a CMT bean throws a system exception, the transaction will still 
commit unless the bean invokes setRollbackOnly. 


If a business method of a CMT demarcated bean throws a system exception, in 
which case will the container always throw a 

j avax. transaction. TransactionRolledbackException? (Choose all 
that apply.) 

Q A. If the method’s transaction attribute is marked 'RequiresNew 5 . 

Q B. If the method’s transaction attribute is marked ‘Mandatory’. 

Q C. If the method’s transaction attribute is marked‘Never’. 

Q D. If the method’s transaction attribute is marked < NotSupported , . 


Which is a subclass of javax.ejb.FinderException? (Choose all that apply.) 
Q A. CreateException 
口 B. NoSuchEntityException 
口 C. RemoveException 
口 D. DuplicateKeyException 
口 E. ObjectNotFoundException 


1 


From which methods can MDBs with CMT demarcation throw application 
exceptions? (Choose all that apply.) 

□ A. onMessage () 

□ B. ejbCreate () 

□ C. ejbRemove () 

□ D. getUserTransaction() 

□ E. setMessageDrivenContext() 

口 F. none of the above 


564 Chapter 10 






exceptions in JB 


What’s true for a local client that receives an exception from an EJB 
invocation? (Choose all that apply.) 

口 A. The exception might be from the java.rmi package. 

Q B. The exception might be an application exception. 

口 C. The exception might be a system exception. 

Q D. None of the above. 

Which action (s) will the container take if a message-driven bean with BMT 
demarcation throws a system exception? (Choose all that apply.) 

口 A. Log the exception. 

Q B. Discard the instance. 

Q C. Mark the transaction for rollback. 

口 D. Commit the transaction unless the bean has invoked 

setRollbackOnly(). 

口 E. None of the above 


From which types of beans can clients receive system exceptions? (Choose all 
that apply.) 

Q A. Session beans with CMT demarcation. 

Q B. Session beans with BMT demarcation. 

口 C. Message-driven beans with CMT demarcation. 

Q D. Message-driven beans with BMT demarcation. 

口 E. Entity beans with CMT demarcation. 
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mock exam answers 





What is true when an entity bean’s client receives ajavax.ejb.EJBException? 
(Choose all that apply.) 


Q A. The client must be remote. 


^ B. The client must be local. 


一 Remote d\ty\U Rcmo-tcE^cft'io^ 


(s_: 洲 


% 


[I C. A client will never receive this exception. 

Q D. The client must handle or declare this exception. 

口 E. This exception can only occur if the client is in a transaction. 

_(s ? e6 ： 微 ) 

Which scenario will cause ajava.rmi.NoSuchObjectException to be thrown? 

(Choose all that apply.) 

ST A. A remote client invokes a method on a stateful session bean which has 
been removed. 

^ B. A remote client invokes a method on an entity bean which has been 
removed. 

Q C. A remote client invokes a finder method with invalid arguments. 

Q D. The container invokes an ejbPassivate() method on a bean that is not 
ready to be serialized. 


- d’wt yb 

o\r 

Okjcd-tN oirouir>dE^cf-tiojr> 
(subdiass of 


3 


Which is a subclass of java.lang.RuntimeException? (Choose all that apply.) 


^ A. 

□ B. 

□ C. 
^ D. 

□ E. 

□ F. 

□ G. 


javax•ejb.EJBException 

javax. ejb. RemoveException 

javax. ejb. CreateException 

javax • ejb. NoSuchEntityException 

java. rmi. Remo teExcept ion 

javax • ejb. Ob j ectNo tFoundException 

java. rmi .NoSuchObjectException 


(API d^s) 
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4 


5 


6 


1 


Which of the following are EJB 2.0 specification guidelines regarding system 7s ? e6 ： 祁-洲 
exceptions? (Choose all that apply.) 

Q A. Bean methods should catch RuntimeException exceptions. 

^ B. Bean methods should wrap unrecoverable checked exceptions in a 

javax • ejb. EJBException exception. 

N 。 , 七 he Coir>-ta*mcv- 

U C. For remote clients, bean methods should wrap unrecoverable checked ;!j “ 

exceptions in a java.rmi.RemoteException. 

Q D. If a CMT bean throws a system exception, the transaction will still - sys-tcm cx.dcf*tioir\s alv/ays 
commit unless the bean invokes setRo 1 IbackOnly . dausc a v-ollka^k 

If a business method of a CMT demarcated bean throws a system exception, in (s_: 奸 - 抑） 
which case will the container always throw a 

javax. transaction.TransactionRolledbackException? (Choose all 

that apply.) 丁 ^ ^ y/rohj because 

Q A. If the method’s transaction attribute is marked ‘RequiresNew’. the ❹ “er s 口 

y/ds v\oi {\\c active v/hch the 

0 B. If the method’s transaction attribute is marked ‘Mandatory’. oddurred* Thcv-c^s y\o 

Q C. If the method’s transaction attribute is marked ‘Never’. {p "tell a dally (-thv-ouah Bv\ 

unless its tnc wallers 

Q D. If the method’s transaction attribute is marked ‘NotSupported’. *tv-a^sa^*tioy> is \rollcd badk ； 


Which is a subclass of javax.ejb.FinderException? (Choose all that apply.) 
Q A. CreateException 
口 B. NoSuchEntityException 
Q C. RemoveException 
Q D. DuplicateKeyException - subdiass of 
E. ObjectNotFoundException 

From which methods can MDBs with CMT demarcation throw application 
exceptions? (Choose all that apply.) 




(s^c6 : 


vn) 


□ A. onMessage () 

□ B. ejbCreate () 

□ C. ejbRemove () 

□ D. getUserTransaction() 

□ E. setMessageDrivenContext() 
F. none of the above 


- /\/lPBs cav\y\oi dcdlav-c / *thv-o>w a^y 
affiliation v/ho v/ould ta 七乙 h 

-them? y\o dl'iCht 
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mock exam answers 



What’s true for a local client that receives an exception from an EJB 
invocation? (Choose all that apply.) 


□ A. 
^ B. 
^ C. 


The exception might be from the java.rmi package. 
The exception might be an application exception. 
The exception might be a system exception. 


口 D. None of the above. 


( s _: 务狐) 
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Which action (s) will the container take if a message-driven bean with BMT 
demarcation throws a system exception? (Choose all that apply.) 

^ A. Log the exception. 

^ B. Discard the instance. 

5^ C. Mark the transaction for rollback. 

口 D. Commit the transaction unless the bean has invoked 

setRollbackOnly(). 

口 E. None of the above 


( s _: 幻《) 


10 


From which types of beans can clients receive system exceptions? 
that apply.) 




A. Session beans with CMT demarcation. 

B. Session beans with BMT demarcation. 


(Choose all 


( s _: 扣) 


□ C. 

□ D. 
M E. 


Message-driven beans with CMT demarcation. 
Message-driven beans with BMT demarcation. 
Entity beans with CMT demarcation. 


- have ho t\\^y 
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11 securft/ in EJB 


♦ 


w 


Protect Your Secret# 



Keep your secrets. Security is about authentication and authorization. First, 
you have to prove your identity, and then we’ll tell you what you’re allowed to do. Security 
is easy in EJB, because you’re only dealing with authorization. You decide who gets to 
call which methods on your beans. Except one problem... if you’re a Bean Provider or 
App Assembler, you probably don’t know who the users are going to be! So you make 
stuff up. You make up roles, like job titles, including Manager, Supervisor, Admin, etc. and 
when someone deploys your application in a real company, that Deployer maps between 
your made-up names (Manager) and real people who will use the app. 


this is a new chapter 
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exam objectives 



SccomCtc^ 



14.1 Identify correct and incorrect statements 
about the EJB support for security 
management including security roles, 
security role references, and method 
permissions. 


14.2 From a list of responsibilities, identify 

which belong to the Application Assembler, 
Bean Provider, Deployer, Container 
Provider, or System Administrator. 


14.3 Given a code listing, determine whether 
& it is a legal and/or appropriate way to 
...programmatically access a caller’s 
1 衅■衅 security context. 

Given a security-related deployment 
descriptor tag, identify correct and 
incorrect statements and/or code related 
to that tag. 

570 Chapter 11 


Ct mecuuL. 

You have to know that you can do two kinds of 
security in EJB: programmatic and declarative. 
Declarative means your security is defined in the 
Deployment Descriptor. You need to know that 
security in EJB is mostly about declaring a set of 
abstract security roles, then declaring which methods 
each of those roles is allowed to call. 

Pay close attention to this in the chapter. You need to 
think about the whole process in a component-based 
development way, to know who is responsible for 
what. You need to know that the Bean Provider usu¬ 
ally won’t have any security responsibilities, but that 
if he does use the isCallerlnRole() method, then he 
must tell the App Assembler what name he hard-cod¬ 
ed in as the argument to the isCallerlnRole() method, 
by putting a security role reference in the DD. You 
must know that the App Assembler’s job is to define 
security roles, method permissions, and role-links 
mapping from the programmer’s made-up role refer¬ 
ences and the App Assembler’s real security roles. Fi¬ 
nally, you must know that the Deployer is responsible 
for mapping (in a vendor-specific way) between real 
users and groups and the App Assembler’s abstract 
security roles, and that this is done using Container 
tools or property files. 

You have to know everything about the DD tags re¬ 
lated to security, including that security role references, 
and role links, are in the <enterprise-bean> section, 
but security roles and method permissions are in the 
<application-assembly> part. You must know how the 
〈 security-identity〉tag is used, and that message-driv¬ 
en beans must never <use-caller-identity>! You need 
to know that the two programmatic security methods 
are called on a session or entity bean’s context. 






security in JB 


Imagine you're writing a payroll application... 


(This will be, without a doubt, \ 

’ the best payroll program ever L 
written. I’m gonna RULE the 
IT department when they see this 
app. Even I am still astonished by 
my superior coding skills... 


O 






ChangePay 


setSalary() 

giveBonus() 

reinburse() 

adjustPay() 


s «si 0h io 

pay 







Employee 


getName() 

setName() 

getSalary() 

setSalary() 

getEmployeelD() 

giveBonus() 

II more 


Well, well... what do we have here? 

Somebody forgot to protect the ChangePay 
methods. I think HI just give myself a little salary 
adjustment. They don’t pay me half of what I*m worth 
anyway... but whatever they re paying Bill, the guy 
who developed this app, ifs waaaaay too much. 

He didn't even think about security! 
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EJB secur/fy 


What caw you do? 


Who really is responsible for making the program secure? How does it happen? 

There’s good news and bad news with EJB security. 

① Security in EJB is easy, Ifs about AUTHORIZATION. 

■ Most of the time, you don’t put any security-related code into your bean classes. 

■ In fact, the Bean Provider does not even think about security, except in very special 
cases we’ll look at in the last part of this chapter. 

■ Security in EJB is about saying WHO can call WHAT. You can restrict access for each 
individual method in your application, to only those individuals that are in a privileged 
Vo/e'(Director, Payroll Admin, Payroll Assistant, etc.) 

■ The EJB part of the security—the part that specifies the roles, and the methods those roles 
can access—is done declaratively, in the deployment descriptor, using simple XML tags. 

■ At the EJB level, it really is as simple as saying, “The setSalaryf) method can be 
accessed by ONLY Directors and Payroll Administrators.” 


② Security in EJB is abstract, lt 9 s NOT about AUTHENTICATION. 

■ The EJB spec makes it very easy to define roles, and to assign roles to methods in order to 
control access to the methods. But the spec says NOTHING about how the system will KNOW 
which real human beings belong to those roles. Somewhere outside of the EJB deployment 
descriptor (and outside the specification) you still have to say that Jack O’Bryan is in the Director 
role (and probably other roles as well). Or say that all Payroll Managers in company XYZ are 
qualified to be in the role of what the application has labeled Payroll Admin. 

■ The spec also does not define how a real human being can be authenticated to the system. 

In other words, there’s nothing in EJB about how you will know that, say, the person logging in as 
Jack O’Bryan really is Jack O’Bryan. This might happen in a variety of ways, although one typical 
option is to have clients authenticate through the web tier (they log in using a browser) of a J2EE- 
friendly web server. 


■ The security in the real operating environment—the company running the application—must have 
a security structure in place, and in a format that your specific EJB server can hook into. Or, at 
the very least, you need a server that lets you specifically configure a security realm. Even if it’s 
nothing more than a list of names, passwords, and the ‘roles’ those names belong to, you still 
need some infrastructure outside of EJB. 
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security in JB 


How to do security iw EJP 


My job is easy. Most of 
the time, I don’t even have to 
think about security when I'm writing a 
bean. And that's good, because my 
philosophy is ''Security is hard... 
don’t do it.” 



My job is more involved. I decide 
which roles make sense in the application. 
For Bill’s payroll beans (plus I added 
some of my own beans to make the complete 
app), I chose Payroll Admin, Payroll Assistant, 
and Payroll Director as the roles. Then I set 
up method permissions in the DD, to say 
which roles can call which methods. 



Annie the 

Application 

Assembler 


Bill the Bean 
Provider 


Annie can set up as many roles as she 
wants... but unless I map real people or groups 
into those roles, it wont matter, because 
NOBODY will be able to call those methods. I 
have to configure the server to use the real users and 
groups in our internal employee system, and I have to 
map between our groups and Annies roles. So lefs 
see... HI make our Payroll Managers group map 
to what Annie called ''Payroll Admin’’". 


o 


O 



Dick the 
Deployer 
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the App Assembler and security 


The App Assembler knows the application. She knows what the methods do, 
and how they’re supposed to be used. The App Assembler knows the abstract 


The 



job: access control 



roles that make sense logically, for this application. For example, she knows W 
that there’s no need for a Marketing role in the payroll application. But she 
knows that there should be a least three levels of access for the app: 

1. People who have full control and can both view and change an employee’s payroll data. 

2. People who can read everything and modify some things. 

3. People who can read some things, but can’t modify anything. 

So her job is broken into two parts: 


① Define the roles 


■ Figure out which roles makes sense in the application, and come up with names for these roles. 
Since the App Assembler might not be working in the real environment where the application will 
run, she’s just making up abstract names. In other words, her names don’t have to correspond 
to anything in the real world. For all we care, she could name the three roles Clown, Mime, and 
Juggler. As long as she can describe them well enough for the deployer to figure out which real 
people belong to those roles, it doesn’t matter that the names are made up. 

■ In the deployment descriptor, define a 〈 security-role> element for each role in the 
application. 

■ In the deployment descriptor, use the <role-name> element to define the made-up name for 
this role. 


② Assign method permissions 

■ Figure out the methods from the client view to which each of the roles should have access. 
Remember, the client view includes not only the methods the Bean Provider declared in the 
home and component interface of the bean, but also the methods of the super interfaces 
EJBObject, EJBHome, or EJBLocalObject, and EJBLocalHome. 

■ In the deployment descriptor, define a <method-permission> element that lists one or 
more security roles and one or more methods. 

■ If she chooses, the App Assembler can can use the 〈 unchecked /〉 element to indicate that 
a particular method doesn’t require any authorization (in other words, anybody can call it). 

■ If she chooses, she can use the <exclude-list> element to define a list of methods that 
nobody can call, ever. In other words, no role will be able to call the methods on the exclude list. 
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security in JB 



You mention an exclude-list. 

If nobody will be allowed to call the 
method, then why is the method 
there? 

A- 

Remember, beans are reusable 
components, meant to be assembled 
in multiple applications. A method 
that makes sense in one application 
might not make sense in another. For 
example, a Productlnventory bean 
that represents products in a database 
might have methods for an inventory 
administrator to add products or 
change prices, etc., but a client catalog 
program using that same bean should 
never need to see anything but the 
read-only methods (i.e.just the getters). 


I would think that the person 
writing the beans would be the one 
who REALLY knows what the roles 
should be. 

A- 

Jr \ m Remember, beans are reusable 
components. Yes, we just said that in 
the previous question, but it works 
here too.The Bean Provider should 
not know exactly how these beans 
are being used. If he gets too specific 
when he designs the code and writes 
the beans,then the beans probably 
won’t work well outside the specific 
payroll application that he has in mind. 

Only the Application Assembler knows 
for sure how the different pieces of the 
application related to one another, and 
which roles make sense.There is one 
small exception to this that we’ll talk 
about later in the chapter, when we 
look at 'programmatic security’. 



Look at the following applications, and try to 
come up with security roles that might make 
sense for these applications. Later, well figure 
out which methods each of the roles should be 
allowed to call. 


1. An inventory system for an online store, keeps 
track of products sold and shipped, inventory 
levels, and prices. 


2. An application for reserving and booking dude 
ranch vacations, through a travel agent. 


3. A rule-based product recommendation system, 
that asks the user a series of questions, and then 
gives appropriate advice on which product the 
user should purchase. 


4. An online match-making /personal ad service. 
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declarative security 



Pefming the roles 


The 〈 security - role〉element 

Create the security roles in the <assembly-descriptor> part of the 
deployment descriptor. Remember, the deployment descriptor has two 
parts: 


1. The <enterprise-beans> section that’s created by the Bean Provider, 
and describes each bean in the application. 


2. The <assembly-descriptor> part that’s created by the App Assembler, 
and describes characteristics of the application as a whole, including the 
ways in which beans refer to one another, most security information, and 
transaction attributes. 


<assembly-descriptor> 

<security-role> 

<role-name>Payroll Director</role-name> 
</security-role> 


<security-role> 

<role-name>Payroll Admin</role-name> 
</security-role> 


<security-role> 

<role-name>Payroll Assistant</role-name> 
</security_role> 

</assembly-descriptor> 



球以:心二 
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Pefming the roles... a better way 

The <sccurity-rolc> element with descriptions 

Descriptions are optional elements for the 
<security-role> element. 

But think about it. 


Think about the poor, overworked, underpaid 
deployer (which in reality, is probably you 
since chances are good that you’re wearing all 
three hats: Bean Provider, App Assembler, and 
Deployer — and what the heck, probably some 


Whafs the 
difference between 
Payroll Admin and 
Director? What was 
she thinking??? 


SysAdmin in there too). 

He’s not a mind-reader. 

<assembly-descriptor> 



<security-role> 


<description> 

I. ake rt MWCH This role is for the employees who have the 

power to view and change all employee payroll 
cas'icv- <ov information. 

wa? $ = ^ </description> 

voles to *cnc j ' <role-name>Payroll Director</role-name> 

•m t </security-role> 

Will rurv. 

<security-role> 


<description> 

This role is for the employees who have the 
power to view all employee information, and 
change some pieces 
</description> 

<role-name>Payroll Admin</role-name> 
</security-role> 


<security-role> 

<description> 

This role is for the employees who have the 
power to view all employee payroll 
information. 

</description> 

<role-name>Payroll Assistant</role - name> 
</security-role> 


</assembly-descriptor> 
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Pefming the method permissions 

The 〈 method - permission〉element 

Everything in a bean’s home and component interface is potentially callable 
by clients. Now that the App Assembler has defined the roles, she can define 
which methods each role is allowed to call. As she did with the security role 
definitions, she’ll put the method permissions in the <assembiy-descriptor> 
section of the deployment descriptor. 


<assembly-descriptor> 


<method-permission> 




<role-name>Payroll Director</role-name> ^ ^ 


<method> 

<ejb-name>ChangePay</ejb-name> 

<method-name>*</method-name> 

</method 〉 

<method> 

<ejb-name>Employee</ejb-name> 
<method-name>*</method-name> 

</method 〉 

</me thod-pe rmi s s i on> 


七卜 ，七 ^ pc\rmissioh says, 
ih ihc ^olc 'Payroll 

7 十 is allowed io ca\\ All 

ahd All 

Employe 

匕 lieirt view. 


<me thod-pe rmission> 

<role-name>Payroll Admin</role-name> 

<method> 

<ejb-name>ChangePay</ejb-name> 
<method-name>reimburse</method-naine> 
</method 〉 

<method> 

<ejb-name>ChangePay</ejb-name> 
<method-name>giveBonus</method-name> 
</method 〉 








<method> 

<ejb-name>Employee</ejb-name> 
<method-name>getSalary</method-name> 
</method 〉 

• • • 

</me thod-pe rmi s s i on> 


</assembly-descriptor> 
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Pefming the method permissions 

Three different ways to specify methods 

You just saw two ways to specify a bean’s method name: the wildcard (*) which 
means ALL methods in the bean, and the actual name of the method. But the name 
alone isn’t always enough. We talked about this before — in the transactions chapter 
we faced the same problem when we had to specify transaction attributes. What 
happens if the method is overloaded? 

Chances are, your design will treat all versions of an overloaded method in the same 
way. But there’s an optional <method-params> element just in case you want, say, 
a particular security role to have permission for only one version of an overloaded 
method, but not the others. 


① By wildcard (*) for ALL methods 

<method> 

<ejb-name>WorldDomination</ejb-name> 

<method-name>*</method-name> 

</method> 


^ astcHsk is 
义卜似 鳴 

f 〜 十吵 i h 

s \y\ic^ac，cs 


(2) By name alone, for all methods with this 
name, regardless of arguments or whether 
they’re in the home or component interface 


<method> 

<ejb-name>WorldDomination</ejb-name> 

<method-name>takeOver</method-name> 

</method> 


tWis means 


③ By name and arguments, to distinguish between 
overloaded methods 


<method> 

<ejb-name>WorldDomination</ejb-name> 

<me thod-name>takeOve r< /method-name> 
<method-params> 

<method-param>String</method-param> 
</me thod-par ams > 

</method 〉 


十〜 r, e ih od ihai 

a bu-t 

h ° 。 仏〜 <>^lo3dcd 
v C\rsiohS. 
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Method permissions interact 
with one another as a union! 

Method permissions do not relate to one another in the same way that transaction attributes 
do. With transaction attributes, using a wildcard says, “Every method in this bean will have 
this attribute unless I say otherwise, by naming a specific method in a different container- 
transaction tag.” In other words, naming a specific method overrides the wildcard setting. 

But with method permissions, using the wildcard says, “All methods in this bean can be 
accessed by this role.” Nothing else you do in any other method permission will change that. 


Transaction attributes 

<container-transaction> 

<method> 

<ejb-name>BigBean</ejb-name> 

<method-name> * </method-name> 

</method> 

<trans-attribute>RequiresNew</trans-attribute> 
〈 /container-transaction 〉 

<container-transaction> 

<method> 

<ejb-name>BigBean</ejb-name> 

<method-name>use01dDatabase</method-name> 

</method> 

<trans-attribute>NotSupported</trans-attribute> 

</container-transaction> 


This says that all methods in 
BigBean will use the RequiresNew 
attribute, EXCEPT the 
useOldDatabase method, which will 
use the NotSupported attribute. 


The second 〈 container-transaction 〉 
overrides the wildcard one, and 
takes the useOldDatabase method 
out of the RequiresNew list and 
moves it to the NotSupported list. 


Method permissions 

<me thod-pe rmi ssion> 

<role-name>Minion</role-name> 

<method> 

<ejb-name>WorldDomination</ejb-name> 

<method-name>*</method-name> 

</method> 

</method-permission> 

<method-permis sion> 

<role-name>Boss</role-name> 

<method> 

<ejb-name>WorldDomination</ejb-name> 

<method-name>learnPlan</method-name> 

</method> 

</method-permission> 


This says that the role Minion 
can access ALL methods of 
WorldDomination. 

AND that the Boss role can access 
ONLY the learnPlan method of 
WorldDomination. 

The second <method-permission> 
adds to the first. 
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Watch out for <unchecked/> 


security in JB 


Think of <unchecked/> as standing in for a <role-name> in a method 
permission. But because of the way method permissions interact, if you have 
a method permission defined for a method using <unchecked/>, it won’t 
matter what other method permissions you set up for that method. One little 
<unchecked/> and it means the method is free for anyone to call, regardless of 
their principal or security role! 


Method permissions with <unchecked/> 


<me thod-pe rmi ssion> 

<role-name>AccountManager</role-name> 



This s ^ys ihai a 


a/ 


㈣ 


<method> 

<ejb-name>Account</ejb-name> 
<method-name>increaseLimit</method-name> 
</method> 

</method-permission 


<me thod-pe rmi ssion> 


\\st 


〈 unchecked/> 、 

<method> 

<ejb-name>Account</ejb-name> 
<method-name>*< /method-name> 
</method> 

</method-permission 


七 wh 。^«??// By saying that 

卜 e ? a mc-thod-pcvmissioh 
ddouh -tKat says /\LL methods avc 
^ docs^i 

ds " WC , sa y aM: 忪 Auo^i 
•methods. They arc all 


The 〈 unchecked/〉element 
overrides ALL oflier mefliod 
permissions fora mefliod. 
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declarative security 


Wait... I just thought of 
something else. Suppose I have 
the same method name in BOTH 
the home and component interface? 
And I want them to have different 
access controls? 



How to deal with a bean that has two 
methods of the same name, but one is 
in the home interface and the other is 
in the component interface. 

(Yes, we lied, there are actually four ways to describe 
a method: by wildcard (*), by name, by name and 
parameters, and by name and interface) 

<method> 

<ejb-name>WorldDomination</ejb-name> 
<method-intf >Remote</method-intf> 

<method-name>takeOver</method-name> 

</method 〉 


The value of <method-intf> must 
be one of these four: 

<method- intf >Remote</me thod-intf > 

<method-intf>Home</method-intf> 

<method-intf>Local</method-intf> 

<method- intf >LocalHome</me thod- intf > 
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security in JB 


The 


Pcployer" 


3 job: mapping actual humans to abstract roles 


The App Assembler knows the application, but the Deployer knows the 
operational environment. We (and the spec) use the term operational environment 
as a fancy way of saying, the business where the application is running. Maybe the 
company bought the app off-the-shelf. Maybe they built it in-house. Doesn’t 
matter. The Deployer works there. He knows the place. Most importantly, he 
knows how security is managed at the company (for example, the company 
might have all the employee names and passwords as part of an LDAP system). 
He’s the best person to know how the abstract roles the App Assembler put in 
should map to real people and groups in his company. 

He has two main jobs: 



① Assigning the security domain and principal realm to the app 


■ The company where the app is running has real employees. Somehow, those employees have a 
way of authenticating themselves to a server, probably with a name and a password. The security 
information in the operational environment has to be configured into the server, in such a way that 
the server can tell who is actually calling the method. 

This happens outside of the EJB specification! In other words, it’s vendor-specific. 

② Mapping users and/or groups to the abstract security roles 


■ The App Assembler made up the abstract security roles that best fit the payroll app. But those 
roles don’t mean anything in the company where the app is going to run. The Deployer has to 
map between what Annie (the App Assembler) defined: Payroll Director, Payroll Admin, Payroll 
Assistant, to what really exists in the Deployer’s company: Payroll Manager, Payroll Supervisor, 
HR Admin. 


This, too, happens outside of the EJB specification, in a vendor-specific way. 


. . 

v For the exam, you don’t need to 
know HOW the Deployer does this, 
^ only that he MUST do these things. 

Remember, the exam does^t expect you toknow about 
any vendor-specific functionality. But m : 
know that it is the Deployed res P onsibi"ty t? do = 

level of mapping between real humans and the App 
Assembler’s abstract roles. 

. 


Note : 咖巧 ^ 
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EJB security 


Principals and Roles, Users and ftroups 

Dan Johnsson authenticates to the system (using his login name and password) and is now 
represented by an instance of type Principal. In a vendor-specific way, the Deployer has told 
the EJB application that Dan’s Principal is associated with one or more roles. So whenever 
Dan, as the client, calls a method on one of the bean’s client interfaces, his Principal (and 
the roles to which that Principal has been assigned) propagates with the call. That means 
every call on the (conceptual) call stack will see Dan’s Principal as the caller. 


0 


/\ 

abstract actor in 
the system (usually 
maps to a person) 


Manager 
Key Account 
Customer 
Payroll Director 
SwedishTeam 
SwingDancers 



Customer 

PayrollManager 

Sweden 

SalsaDancers 


In EJB 


① Principal 

The client, authenticated to the system, is represented by a java.security.Principal object. This 
Principal is an abstract representation of some thing associated with a name, but there’s no guarantee 
that the Principal name matches the login name of the client. It all depends on how your system 
handles security authentication. And don’t be too attached to thinking that a Principal is always a 
unique individual. Sometimes a Principal represents a larger group like, say, SysAdmin.The Principal 
is associated with one or more abstract security roles that the App Assembler defined. About the only 
useful thing a bean can do with a Principal object is get its name (aPrincipal.getName()), but that’s 
risky, because you won’t be able to know exactly what that name represents unless you know the 
exact environment in which the bean is running. Yuck. 


② Role 

In EJB, a security role is an abstract role defined by the App Assembler, and although it doesn’t match 
anything in the real world, the Deployer will map real users and groups in the company where the 
application is running, to the abstract roles. For example, the “Employee” abstract role might map to 
the “Slaves” group in the Deployer’s company. 


In the operational environment 


③ Users 

Users are people in the real environment. Real users. Living, breathing, humans. They’re represented 
in the real environment in some way, but of course in EJB we have no way of knowing in advance 
that, say, the company uses an LDAP server to hold the user security information. Typically, users 
are mapped to a log-in name and password, and that information is stored somewhere, and if you're 
lucky and make the right server decision, your EJB server can be configured directly to the system 
holding your security info. Pretty much the last thing you want to do is sit there and type 10,000 user 
names and passwords into your EJB server’s property files, simply because your EJB server wasn’t 
compatible with whatever your company is using to store user security information. 


④ Groups 

Typically, security information organizes users into one or more groups, often by department or 
location. The Deployer can often map directly from groups to abstract security roles, but he might also 
have to map individual users. 
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security in JB 


OK, I know I'm not supposed 
to be thinking about this when I write 
my code... but there's something bugging me. 
Looking at the deployment descriptor, it lets 
you say who can access which bean type. 
But you can’t say which instance of 
that bean type. 




I know what he's getting at, because 
I was thinking the same thing. What do 
I do if I want employees to be able to have 
access to some of their own data—but only 
their OWN data. How do I set individual entity- 
level control? Otherwise, I’d have to either block 
ALL employees from these methods, or let ALL 
employees have access to the methods that would 
work on ANY entity bean. How can I let the role 
of employee call, say, getSalaryO but only 
see his OWN salary? 
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programmatic security 


Class-level vs. mstawce-level security 

Whew declarative security is wot enough, you might weed programmatic 
security to restrict access to a specific instance of a beawl 

So far, all the security we’ve looked at has been declarative... not hard-coded into 
the bean class. Declarative security is cool because it supports the whole idea 
of component-based development~you can customize the bean at deploy¬ 
time without touching the code. Company A might be using a bean in one 
application, and need a particular type of access control that’s completely 
different from the way Company B is using that same bean. Or even two uses 
of the same bean in the same company might need different access control. 

But declarative security is at the class-level. You specify which methods a 
particular role can call, but it means that role can call the method on ANY 
instance of the bean class. If you need instance-level security, you can’t do it 
in the deployment descriptor. But you can do programmatic security, which 
of course you already know... you’ve seen the two security-related methods in 
SessionContext and EntityContext. 



public void doSecurity() { 

java.security.Principal p = context.getCallerPrincipal (); 
String name = p. getName (); 

// now do a comparison by checking the name 
y * // against the persistent field in the bean 

_ 乂 ; // that should match the principal name 



But be careful! There is no guarantee that the name coming from the getName () method 
on the principal matches the user’s log-in name. So you have to assume that as soon 
as you put programmatic security into your bean, you’re drastically reducing it’s 
reusability, and portability. And it means the Bean Provider might need to be 
more tightly-coupled to the operational environment than you’d normally want. 
Because the Bean Provider is making an assumption that the name coming 
from the getName () method will match a persistent field in the entity bean, 
and that might not be true in all environments, depending on how your system 
handles security. 
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programmatic security 


security in JB 


Using programmatic security to 
custom-tailor a method 

We just looked at getCallerPrincipal(), to see how you could find 
out exactly WHO the container believes is calling the method. But 
we can also use the isCallerInRole() method to test whether the 
principal (whoever it is and in this case we don’t care) is a member 
of a specific role that we do care about. Imagine that you have a 
private pricing method, called by one of your business methods, 
that checks to see if this customer authenticated as a member of 
your special VIP customer group. If he is, you treat him differently 
than if he isn’t. Maybe you give him a discount. Maybe you raise 
the price. Whatever your business logic tells you to do. 


private void determinePrice() { 

if (context. isCallerlnRole (''VlPCustomer^) ) { 
// treat customer well 
} else { 

// treat him like the loser he is 


Besides the obvious problem with hard-coding security information 
(cuts down your reuse, increases the chances that things won’t 
work in a portable way, etc.), there’s another big problem — how 
the heck does the Bean Provider know in advance what roles the 
App Assembler is going to assign? 

He doesn’t. Or at least, he probably shouldn’t. We know, we know. 
In reality, the Bean Provider and App Assembler are, if not the 
same person, closely related (professionally-speaking, of course). 
But we’re still pushing for a component-based development model 
here, and at the very least, we want the App Assembler to take 
what the Bean Provider has done and somehow fit it into her own 
application. And that might mean integrating the bean with beans 
from other providers. 

So now imagine this scenario: Annie the App Assembler is 
building a new app from four existing beans, two of which came 
from different providers. Providers who didn’t work for the same 
company or know one another. How could they have communicated 
in advance, to know which roles Annie was going to choose for her 
application? 


Widi isCallerInRole(), you 
can use security information 
to tailor the way a uiediod 
runs, depending on wdiicli 
role called ilie method. 

This is usually NOT a good 
way to Kandle security. To 
control access to a method, 
you’re mck better off using 
ike mediod permissions 
to stop an unauftoized 
role from ever calling the 
method. 

But you can still USE the 
caller's role information to 
do odier non-security teigs 
in your code. 
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The problem with isCallerlnRoleO... 

the Peaw Provider hard codes a role name, but how does 
he know what roles the App Assembler will use? And 
what if there's more thaw owe Provider? 


I'll call the 
big accounts role 
'VIPCustomer M in my 
code. 



• 丨 I 

Bill provided bean A 


See the problem? I have 
to integrate these beans into one app, 
but Bill picked the name 、 'VIPCustomer" to 
hard-code into his bean, and RaySunshine 
there decided the role should be called 
、 'EnlightenedCustomers” So now I have to somehow 
map THEIR completely made-up names to the 
abstract security roles that I put in the deployment 
descriptor. I have to tell the app that both of their 
names REALLY mean “KeyAccounts" And how will I 
even KNOW that they used these names, if 
I don’t see the source code??? 


I'll call the role for 
important accounts 

'Enl ightenedCustomers # 


% 



RaySunshine 
provided bean B 


Annie needs to use BOTH 
beans in her app, but she 
wants to define her role 
name as %% KeyAccounts 



The App Assembler must map 
between the programmer’s 
hard-coded (completely fake) 
role name, and the abstract 
role she wants to define for 
this application. 

abstract role name: KeyAccounts 

bean A role name: VIPCustomer 

bean B role name: Enlightened- 
Customers 
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programmatic security 


security in JB 


Map declarative security roles to the 
programmer^ hard-coded (fake) roles 

The App Assembler maps between security role references (hard-coded 
role names the programmer made up) and security roles (abstract role 
names she chose for this app) using the 〈 role—link 〉 element. 


Bean Provider 


Oh yeah... the App 
Assembler needs to know that 
I put a role name in my code. I’ll 
make a security role reference 
in the DD I make for this 
bean... 





]terprise-beans> 

<session> 

<ejb-name>ShoppingCart</ejb-name> 

• • • 

<security-role-ref> 

<description> 

this role should be assigned to the 
accounts that get special VIP pricing 
〈 /description 〉 

<role-name>VIPCustomer</role-name> 
</security-role-ref> 卜 A/lATCH- 

ro \ t v^M OVA W 


</session> 

</enterprise-beans> 



or\C 


context. isCallerlnRole (''VIPCustomer y 


App Assembler 


I have to go 

into his bean description and 
add a <role-link> element for 
this security role reference, so 
that the Container will know that 
l VIPCustomer 〃 really means 
''KeyAccounts' 




Ass C h ， blc\r s ifruc absi^i ^ 


<security-role-ref> 

<description> 

this role should be assigned to the 
accounts that get special VIP pricing 
</description> 

<role-name>VIPCustomers</role-name> 

<role-link>KeyAccounts</role-link> 

</security-role-ref> 
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EJB security mapping 


The complete security mapping picture 


《 security-role-ref > 




<security-role> 



users and groups real people 



App Assembler maps the 
programmers hard-coded 
security role references to 
her abstract security roles, 
using the <role-link> element. 


Deployer maps the App 
Assemblers abstract 
security roles to users and 
groups in the Deployers 
company, using a vendor- 
specific mapping (could be a 
properties file). 


Someone in the operational 
environment sets up users 
and groups in the real 
company. Probably some kind 
of sys admin responsible 
for assigning log-in info and 
passwords to employees. 


Where and how the mapping happens 


In the EJB 
Deployment 


In a vendor- 
specific way 


In a company- 
specific way 



Jis is ihc 

the ? a^ri you have io k h ow 


ahd 

Oh the exam 


^11 Jpmd -tw«s ou-t youv way out the sdopc 

wdiov/pv-odi^-t dot^cy>-tat»ov> a bea" dcvdopc/s job 
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security in JB 


Use <ruw-as> security idewtity to 
pretewd someone else is calling... 


When a client calls a method, the Container always 
knows the client’s Principal, which includes the abstract 
security roles the Deployer assigned to that Principal. 

And remember, the caller’s security context is propagated 
throughout the application as the client’s original method 
goes about doing its work. Each method called in the 
conceptual call stack will get the security context along with 
the call. 

But... let’s say that you don’t want the client’s security context 
to keep propagating. Let’s say that when the client calls Bean 
A, and Bean A in turn calls Bean B, you want Bean B to think 
that someone else is calling. In other words, what if you want 
Bean A to pretend to be someone else? That way, any bean 
that Bean A calls will think the Principal (and roles) of the 
caller is something other than the original client’s. 

Why would you do this? Bean B might have tighter access 
control. Perhaps Bean B won’t allow outside clients to call its 
methods, so it doesn’t have method permissions set up for 
any of the abstract roles mapped to clients users and groups. 
But perhaps you have a special role set-up just for other 
beans, and Bean B will take calls from other beans, as long as 
those beans are in that role. 


Now whenever I call another bean 
in the application, that bean thinks 
I’m someone special. Someone cooler. 
Someone with power, who can really GO 
places. Someone a LOT more interesting 
than the client who called the business 
method that started all this... 



When you want the bean to BE some¬ 
one other than the calling client 

<enterprise-beans> 

<session> 

<ejb-name>BeanA</ejb-name> 


Explicitly saying that you want the 
calling client’s identity to be used 

<enterprise-beans> 

<session> 

<ejb-name>BeanA</ejb-name> 


<security-identity> 

<run-as> 

<role-name>SuperBean</role-name> 
</run-as> 

</security-identity 〉 



</session> 

</enterprise-beans> 


A?? 


<security-identity> 

<use-caller-identity/> 
</security-identity 〉 



</session> 

</enterprise-beans> 


TWis is vA>a*t 70 ” 叶 W 
^ VO'A (W 七 
pu-t rn a <scduv«-t 7 - 
如七士 /> eU ⑼七 at all. 
£0 y° u do^-t *to say 

七 Wis, bu 七 y ou 灼 . 
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<run-as> security identity 


Security context propagation 
with <ruw-as> 


Client calls with a security 
context that says she's a 
member of the ''customers 1 
role. 


Rather than propagate the 
client's security identity, 
Bean A takes on the role 
of 'SuperBean, then calls a 
method on Bean B. 



C 3 


Bean A 


Client in the 
customers' role 


Message-driven beans must NOT 

say <use-caller-identity/>!! 

whirh ca ,i er would that be? Message-driven beans don’t 
HAVE a calling client! So watch out for a =eploym=n 

讀 



Bean B doesn’t know about the 
original client, and thinks the 
callers security identity is 
'SuperBean. Unless Bean B has 
its OWN run-as identity, it will 
propagate 'SuperBean with any 
calls Bean B makes on other beans. 


Still Bean A, 
but now running 
as 'SuperBean* 




Bean B 


Bean A s 〈 Security-identity 〉 

is not about Bean A 
should see as its caller, but 
ratker wiM Bean B will see 

wiien Bean A calls it. 

In otker words, 〈 security - 
idetttiiy> is not about 
dianging the incoming 
client identity, but about 

cKanging wiiatilie bean 

propagates as the outgoing 
identity, ^viienflie bean 
calls adier beans. 

(ukc _ 七—户 m 

: t ：^:: ⑽ 

As as V.c *«s 7 糾代 
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"TKcck Sxam 


What’s true about security for EJBs? (Choose all that apply.) 

Q A. All security policies must be expressed declaratively. 

Q B. The default security principal under which a method invocation is 
performed is that of the component’s creator. 

[I C. Using EJBs, method permissions can be declared using EJB QL in the 
deployment descriptor. 

口 D. Security authorization can be bypassed on a method by method basis. 

口 E. Security authorization can be bypassed on an instance by instance basis. 

What’s true about methods that should run without being checked for 
authorization? (Choose all that apply.) 

Q A. They can be listed in the <exclude-list> element. 

Q B. They can be listed in the 〈 unchecked 〉 element. 

Q C. When the <unchecked> element is used, it should be placed where the 
<role-name> element normally occurs in the deployment descriptor. 

口 D. When a method permission relation specifies both 〈 unchecked〉and a 
security role, the container will use the security role. 

Which role(s) should typically define the appropriate security policies for an 
application? (Choose all that apply.) 

Q A. bean provider 
Q B. application assembler 
Q C. deployer 
Q D. system administrator 
口 E. server provider 
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coffee cram mock exam 


4 


In which of the following methods can a stateful session bean invoke the 
isCallerlnRole method in order to perform a security check? (Choose all 
that apply.) 


□ A. ejbCreate () 

□ B. ejbActivate () 

□ C. e jbPassivate () 

口 D. None of the above 


Which are the bean provider’s responsibilities when making an application 
secure? (Choose all that apply.) 

口 A. Assigning the security domain to the application. 

口 B. Authentication of principals. 

口 C. Mapping the principals used by the client to the principals defined for 
the bean. 

Q D. None of the above. 


In which of the following methods can a CMP entity bean invoke the 
getCallerPrincipal() method in order to perform a security check? (Choose 
all that apply.) 

□A. ejbCreate() 

□ B. ejbActivate() 

□ C. e jbPassivate () 

□ D. ejbPostCreate() 

口 E. Business methods 


7 


In which of the following methods can a BMP entity bean invoke the 
getCallerPrincipal () method in order to perform a security check? 
(Choose all that apply.) 


□ A. ejbLoad () 

□ B. ejbStore () 

□ C. e jbPassivate () 

□ D. ejbPostCreate() 

口 E. Business methods 
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security in JB 



When describing method permissions in the deployment descriptor for a 
specific bean, what’s true? (Choose all that apply.) 


Q A. A wild-card character can refer to all of the bean’s methods. 

Q B. Individual overloaded methods cannot be distinguished from each 
other. 

Q C. A method in the home interface cannot be distinguished from a 
method with the same name in the component interface. 

口 D. Individual methods can be referred to. 


The <role-name> element can be used within what other security related 
deployment descriptor element(s)? (Choose all that apply.) 

Q A. <security-role> 

Q B. <run-as> 

Q C. <method-name> 

Q D. 〈 exclude - list 〉 

口 E. <security-role-ref> 


10 


Which roles have what responsibilities when implementing security for EJB 
applications? (Choose all that apply.) 

Q A. The Application Assembler typically specifies when run-as identity 
should be used in an application. 

口 B. The Bean Provider maps security role references to security roles. 

口 C. The Bean Provider is typically responsible for assigning the security 
domain and principal realm to the application. 

口 D. The Deployer maps security role references to security roles. 


11 


Within the 〈 security-role - ref> deployment descriptor element, which 
sub-elements are optional? (Choose all that apply.) 


Q A. <role-name> 

Q B. <role-link> 

□ C. <description> 

Q D. None of the above are optional 
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declarative security 




% 


3 


What’s true about security for EJBs? (Choose all that apply.) 

Q A. All security policies must be expressed declaratively. 

Q B. The default security principal under which a method invocation is 
performed is that of the component’s creator. 

Q C. Using EJBs, method permissions can be declared using EJB QL in the 
deployment descriptor. 

ST D. Security authorization can be bypassed on a method by method basis. 

口 E. Security authorization can be bypassed on an instance by instance basis. 

What’s true about methods that should run without being checked for 
authorization? (Choose all that apply.) 


( s ? e 6： 辦-柳 


(s_ •• 州 ) 


Q A. They can be listed in the <exclude-list> element. - p 0 y methods "that HBVBR b || 
^ B. They can be listed in the 〈 unchecked 〉 element. 2 


ar c. When the <unchecked> element is used, it should be placed where the 
<role-name> element normally occurs in the deployment descriptor. 

Q D. When a method permission relation specifies both 〈 unchecked〉and a 
security role, the container will use the security role. 

Which role(s) should typically define the appropriate security policies for an 
application? (Choose all that apply.) 

口 A. bean provider 
^ B. application assembler 
^ C. deployer 
Q D. system administrator 
口 E. server provider 


( s ? e 6： 物-砂 ) 
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In which of the following methods can a stateful session bean invoke the (s_: 

isCallerlnRole method in order to perform a security check? (Choose all 
that apply.) 


A. ejbCreate() 

^ B. ejbActivate() 
^ C. ejbPassivate() 

口 D. None of the above 


Which are the bean provider’s responsibilities when making an application 
secure? (Choose all that apply.) 

Q A. Assigning the security domain to the application. T ypidally "the Pcf loycv-^s job 
Q B. Authentication of principals. 

Q C. Mapping the principals used by the client to the principals defined for 
the bean. 

^ D. None of the above. 


"(s ? e6 ： W - 柯 ) 
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In which of the following methods can a CMP entity bean invoke the 
getCallerPrincipal() method in order to perform a security check? (Choose 
all that apply.) 

ejbCreate() 

e jbActivate () 一讪。娜以 ^ be? 

ejbPassivate () 
ejbPostCreate() 

Business methods 


4 A 

□ B. 

□ C. 

D. 

E. 


(s ? e6 ： 
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In which of the following methods can a BMP entity bean invoke the 
getCallerPrincipal () method in order to perform a security check? 
(Choose all that apply.) 


aT a. 

^ B. 
□ C. 
tjT D. 
^ E. 


ejbLoad () 


ejbStore() 
ejbPassivate() - 
ejbPostCreate() 




Business methods 
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When describing method permissions in the deployment descriptor for a (s?c6 : W … 

specific bean, what’s true? (Choose all that apply.) 

A. A wild-card character can refer to all of the bean’s methods. 

口 B. Individual overloaded methods cannot be distinguished from each : 

other element docs "this 

Q C. A method in the home interface cannot be distinguished from a 
method with the same name in the component interface. 




D. Individual methods can be referred to. 


The <role - name> element can be used within what other security related 
>yment descriptor element(s)? (Choose all that apply.) 


(s ? e6 ： 竹今 - W) 


deploy 

81 A. <security-role> 

^ B. <run-as> 

Q C. <method-name> 

Q D. 〈 exclude-list> 

E. 〈 security—role-ref> 


10 Which roles have what responsibilities when implementing security for EJB 
applications? (Choose all that apply.) 


州肩) 


A. The Application Assembler typically specifies when run-as identity 
should be used in an application. 


□ 

□ 

□ 


Usudllv dc-fmcd by -the 


B. The Bean Provider maps security role references to security roles. assc 

C. The Bean Provider is typically responsible for assigning the security 
domain and principal realm to the application. 

D. The Deployer maps security role references to security roles. 


Within the 〈 security - role-ref> deployment descriptor element, which 
sub-elements are optional? (Choose all that apply.) 


(syc6 - *52^) 


口 A. <role-name> 

B. <role-link> 

^ C. <description> 

Q D. None of the above are optional 


Usually dc-f'mcd by -the dsscw'bicv- 
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12 a bean’s enVirpnnient 





The Joy of Deploym^it 



YOU Worked hard on that bean. You coded, you compiled, you tested. About 
a hundred zillion times. The last thing you want to touch is already-tested source code, 
just because something simple changed in the deployment configuration. Maybe the name 
of the database is different. Maybe you hard-coded a tax-rate (remember — bean’s can’t 
access property files). And what if you don’t even have the source code? Maybe you got 
it from Beans-r-Us, and they won't sell you the source (not on your budget, anyway). EJB 
supports bean reuse through the Deployment Descriptor and a bean’s special environment. 


this is a new chapter 
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13-1 Identify correct and incorrect 

statements or examples about an 
enterprise bean’s JNDI naming. 

13.2 Identify correct and incorrect 
statements about the purpose and/or 
use of the deployment descriptor 
elements for environment entries, 

EJB references, resource manager 
connection factory references, 
including whether a given code listing 
is appropriate and correct with respect 
to a particular DD element. 

13.3 Given a list of responsibilities, identify 
which belong to the Deployer, Bean 
Provider, App Assembler, Container, 
Sys Admin, or any combination. 

1.2 Given a list of technology 

specifications, identify which are 
requirements for an EJB 2.0 container. 


You must know the ways in which a bean can be custom¬ 
ized at deployment time, without changing source code. 
When a bean does a JNDI lookup using the bean’s 
own special environment, you must know how the code 
relates to what’s in the deployment descriptor, and a 
bunch of finicky details that mean the difference between 
a successful deployment or one that won’t deploy. Or 
much worse... one that deploys but blows up sometime 
later, while its running. 

You need to know what is and is not guaranteed by the 
EJB 2.0 specification. For example, an EJB 2.0 container 
is not required to support JXTA, JMX,Servlets or JSPs, 
but it is required to support JNDI, JMS, and JAXP. You 
need to know what EJB really gives you. 

You also need to know what you can and cannot do in 
EJB, if you want to make a bean that is portable across 
all EJB 2.0-compliant containers. For example, you can’t 
listen on a ServerSocket, but you can create a client 
Socket. You can’t access the server’s local file system, 
or make your own threads. But you can make your bean 
class extend another. 


1.3 Identify correct and incorrect 
statements or examples about EJB 
programming restrictions. 

1.4 Match EJB roles with the 
corresponding description of the role’s 
responsibilities, where the description 
may include deployment descriptor 
information. 

1.5 Given a list, identify which are 
requirements for an ejb-jar file. 


You need to know about the EJB roles (Bean Provider, 
Application Assembler, etc.) and who does what during 
development and deployment. Although you won’t have 
many questions about this, it’s an area the exam beta 
testers struggled with, so if we were you, we’d study this 
part carefully. 

Finally, you must know what is and is not supposed to be 
in an ejb-jar file. For example, the home and component 
interface must be there (unless you’re using a message- 
driven bean), but the stubs must not be there. 
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a bean’s environment 


I just LOVE to change 
source code. Thafs why I have 
a high-paying job working in 
a respected IT company... 
cafeteria. 



Raise your hand if you like changing 
your source code every time you need 
to change the way your bean behaves. 


Of course you don’t like going back to your source 
code just because, say, somebody changed the name 
of the database. You already know that you can 
change transaction attributes and security access just 
by tweaking the deployment descriptor. But wait... 
there’s more! 

Every EJB container gives your bean its own special 
environment, that your bean can use to look up four 
different things: 

■ Environment Entries 


These are deploy-time values (so you don’t have to 
code in values like the current discount percentage or 
tax rate). 


■ Resource Manager Connection 
Factories 

You'll use these to get a connection to a database. 


■ Enterprise Bean References 

When one bean wants to look up another bean. You’ll 
do this a lot! Most designs involve at least some level of 
bean-to-bean communication. 


■ Resource Environment References 

You'll use this to get a reference to something called 
“an administered object” from the server, like a JMS 
destination. 
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A bean’s special place - java:comp/cwv 

Your bean is entitled to aJNDI context all its own. A special 
place that’s just for your bean, where your bean can look things 
up. It all starts with an InitialContext, but the java:comp/env 
subcontext is where the bean begins navigating when he wants 
to look something up. 



look stufW. 


This b 


taxRate 


二 ssr 


A JNDI Virtual 
directory tree* 


(reference to Advisor) 


(reference to a DataSource 
for the Customer database) 


^ ^ look up 
oi ^^ hsihihc ^ 
J，。，/ ⑽ b 


U VA\> a Pa-ta^0VAv6c 
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a bean’s environment 


Put ifs wot per bean iwstawce... 

Ifs per bean home 

The scope of a bean’s environment is for all beans from the same home. If 
you deployed a particular bean type into your server three times, each of 
the three deployments would have it’s own unique home, so there’d be 
three different environments. 




All beans from the 
same home have the 
same environment 


CustomerBean 


all the other Customer Beans 


InitialContext ic = new InitialContext(); 

Double discount = (Double) ic • lookup (''java: comp/env/custDiscount "〉； 



This 


㈤ S 二 

Cus^drBca, vu hS -this todt. 
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deploy-time customization 


Environment subcontexts 

java:comp/env/jdbc/CustomerDB 




A suUo^i wc 一 ed (jdk，by 
faltKougK is Ji 

v*c<\uiv*cd, a^d wc dould have said 
java*dorwp/Chv/ Cus-tor^cvDB 


TW〆 f 以 s J ； 

\ooWm^ U ；： ^ 

； c) 




Sltat 


in a bean’s business method: 

InitialContext ic = new InitialContext(); 

DataSource ds = (DataSource) ic • lookup (''java: comp/env/jdbc/CustomerDB") 
Connection conn = ds.getConnection(); 


: 上 ㈣ 1 / 

bcar> looks somctW^V w 

cy>v\voy>w'CV'*t 

TV>C rtto^tr^s Hi 

all OPBC 

icsourdc r«air>ayv 

Ubor\ts t -tv>c ^a.r subto^ w 

乙 om^Ws a 朽 (Ua' 7 oTs S 

\i *«s U uvi to^ttho^ 



a reference to the connection 
factory for the customer database 
named 4 、 CustomerbB〃... or is it? 

-the Wk docs -the 

Kr: 二 t :#， 
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a bean’s environment 


Deja vu." ifs the same issue 
we had with security. I have 
to put SOMETHING in code, but 
I don’t know the real name of the 
database. Hmmmm. … 





How can we deal with this? How does the 
programmer hard-code a lookup String like 
“java:comp/env/jdbc/CustomerDB” without 
knowing how the database was configured 
into the server? 



(hint: how did we deal with it earlier when 
the Bean Provider used programmatic 
security with isCallerlnRole(“someRole”)？) 
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Ifs simple... 

if the programmer puts a made-up JNPI name in code, 
he has toamiouwcc that to the deployer in the l?R 


The Deployer has no clue what the Bean Provider put in code, unless the 
Bean Provider: 


A. Tells him. 

B. Writes the names on a sticky note and sticks it on the Deployer’s monitor 
or 

C. Declares references in the Deployment Descriptor, complete with helpful 
descriptions that make it very clear what the Deployer is supposed to map to 
the programmer’s made-up names. 


The deployer gets really 
pissed off if you don't declare 
your JNDI lookup strings in 
the deployment descriptor. Ask 
me about the fight we had last 
month. Seriously. Ask me... 



He better declare all his 
JNDI environment references 
in the DD, so I can map them to 
REAL names that only I know. And 
if he doesn’t, I'll show him what 
three years of Pilates can do. 



Declares the made-up JNDI names 
in the Deployment Descriptor, for 
the Deployer. 


Maps the programmers made-up/ 
fake names to the REAL JNDI 
names under which the resources 
were deployed or configured into 
the server. 
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Environment entries: deploy-time constants 


Imagine you’re writing a simple checkout bean for an online shopping 
cart system. You don’t know where that bean might end up. Even if you do, 
you know that things like tax rates and discount policies can change, even 
within the same company. 

Environment entries let you write your code using a variable that you’ll fill 
in at runtime using aJNDI lookup. Remember, the Bean Provider chooses 
the name, and it’s up to the Deployer to fill in the value. 

in a bean’s business method: 


"this is -the pav-t o-f 
仏 c lookup that must 

9® ^ the DD 


^1/ 


工 nitialContext ic = new 工 nitialContext(); 

Double dbl = (Double) ic.lookup(''java:comp/env/smartCustomerDiscount"); 
customerDiscount = dbl.doubleValue(); 

// use the primitive double value to calculate the discount 




/〆 


in the Deployment Descriptor 

<entity> 




- 0 w. W. 


Co^ 


<env-entry> 

fv*o^va^wcv <description>discount for smart customers</description> 

n\Bdt f <env-entry-name>smartCustomerDiscount</env-entry-name> 

<env-entry-type>java.lang.Double</env-entry-type> 
<env-entry-value>0.05</env-entry-value> 


if you V^avc amy 
dom^assion at 
all, youll m a 
dcs 6 v-i\>tioir\ -fov- 
^>oov* Poploycv* 



i\\t -type wust be 

</env-entry> T crtW a or d 

tlass 


You can’t change a 
vsluG dyn3mic3lly! 

Once a bean has been deployed, there is 
NO WAY to change the value of the envi¬ 
ronment variable! The only way to update 

the value a bean sees is to redeploy the 
bean with the new DD. 


</entity> 

The value is optiohal (or i\\t Bca^ Pvovidcv, Ut he w use 
七 Vis dcmcht -to supply a default But the Pcploycir /\^U£T 
ck\suvc 七 1 ^七 *thcv"c s 3 valid vdlue bc-Povc the bedh is deployed* 

Ehviv-Ohmcht Chivies a\rc di^cvcht -fvom the othev- 
dusWiz^tiohs ih that i\\t Dcploycv- doesn't map -fv-om the 
Bca" Pv-ovidcv-s -to some othev veal Mmc. Erwivo 一伙七 
civbrics dov^i exist uhtil the Bcah Pv-ovidcv- says they do, by 
pu-ttmg ih *thc <ChV-Ch*t\ry>. /\s lohj as tlic <ChV-Ch*tv-y> has a 
value Uch its deployed, 七 he chviirohmcht Chtiry will be dv-catcd. 
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deploy-time customization 


fJiereiareoiP 

Dumb Questions 

Why can’t you just use Java property files 
instead of environment entries? 


A ： 


You’re not allowed to use properties because 
you can’t access the file system to read them in, and 
you don’t have any control over system properties (for 
example, you have no way to set a property as a JVM 
command-line argument.) 


Why can’t I have an environment entry that’s 
shared among multiple beans in the same app? Or at 
least within the same ejb-jar? 

A- 

Because... because you can’t.There’s simply 
no mechanism for sharing the bean’s environment 
because that would defeat the whole purpose of the 
bean having his own private space. Having a bean’s 
environment prevents what would be an extremely 
likely disaster: naming collisions between different 
beans! In other words, different beans deployed with 
environment entries (or other references) that use the 
same name. 

If you have a shared resource or environment entry, 
you MUST configure it with each bean you deploy.This 
is NOT per Deployment Descriptor, but per every indi¬ 
vidual bean, regardless of where the bean lives. 


Environment entries must 
be one of these types: 

■ String 

■ Byte 

■ Short 

■ Integer 

■ Long 

■ Float 

■ Double 

■ Character 

■ Boolean 


Only Strings 
and wrappers 
are allowed for 
environment 
entries 


mtSit! 


You MUST know 
the scope of 
an environment 
entry! 


You’re expected to know that 
environment entries are private and 
unique to each home. If you deploy 

an environment entry ‘foo’ with a 
value of 10, for the Customer bean 
all instances of CustomerBean will 
qet that same value when they do a 

lookup using java:comp/env/foo from 

a business method. 

But your environment entry c foo 
does NOT cause a naming colli¬ 
sion with any other BEAN type 
thafs been deployed with the 
same environment entry name. 
Customer bean’s ‘foo’ is not the same 
as Advice bean’s‘foo’，evert though 
the lookup strings are identical: 

ic.lookup(“java:comp/env/foo’’)and 

even if both beans are in the same 
ejb-jar or enterprise archive (.ear). 

But we're not done yet... a single 
bean type must NOT be deployed 
with more than one ‘thing’ of the 
same name. So you can J t call an en¬ 
vironment entry Wanda resource 
manager connection factory ‘foo in 
the Customer bean. As long as you 
use subcontexts, though, you J re OK. 
Because ‘jdbc/foo’ is different from 
just alone. So you CAN have 

both: 

java:comp/env/foo 

and _ 

java:comp/env/jdbc/foo 

but NOT two things named: 

iava:comp/env/foo, even if those two 
things are different resource types. 
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a bean’s environment 


■t’s subcontexts all the way down 

Remember, yourjava:comp/env space is just a subcontext. A special one, 
sure, but still a context. So you can save that in a Context variable, and save 
yourself from having to retype “java:comp.env” every frickin’ time you want 
to look something up. 

Saving your special environment context: 

InitialContext ic = new InitialContext(); 

Context mySpecialPlace = (Context) ic • lookup (''java: comp/env"); 

// now look something up on mySpecialPlace 

Double dbl = (Double) mySpecialPlace.lookup(''smartCustomerDiscount"); 


—! 


java:comp/env 


taxlnfo 


obj 




V 



Using a subcontext 


tav.|^o »s a 严 A 此 

oJf locals • 




e 灼 t- 


InitialContext ic = new InitialContext(); 

Context myTaxInfoCtx = (Context) ic. lookup (''java : comp/env/taxlnfo^); 
// now look something up on myTaxInfoCtx subcontext 
Double dbl = (Double) myTaxInfoCtx. lookup (''taxRate A, ); 

/ 


out J 糊 lookups EXCEPT stubs 

代 “ 伙把 )， so all you 

is a plaih old cast. 


svA)6o 灼七七 


taxRate 


Creating a subcontext 


|y, PP k 严 C 

a svA>to 於七 七 . 


A subcontext exists simply because you say it does. If you type “java:comp/ 
env/foo/bar” into your lookup code, you’ve said, “There is a subcontext in 
my environment named “foo”，and it contains the object “bar”. As long as you 
use the same subcontext in the deployment descriptor when you deploy the 
bean, the subcontext will magically exist, just because you said it does. In other 
words, you don’t have to go through a process of somehow creating a new 
JNDI context and naming it. Act like it’s there, and it’s there. Don’t you wish 
everything worked that way? 


<env-entry-name>taxInfo/taxRate</env-entry-name> 


w ta%k-fo/ w bcW w la^Ra*tc , 

au-tomatidally dv-ca-tcs i\\t -ta^Ra-tc 
subdorrtwt yi\\tr\ tWis bca^ is deployed 
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deploy-time customization 


Resource manager connection factories 
(think: database) 


Any bean can use a database. In fact, even an entity bean with container- 
managed persistence can get a connection to a database, as long as its using 
that database for something other than managing its own persistence. The 
code is simple: look up a DataSource, and ask it for a Connection. Once you 
have a Connection, you can send JDBC statements to do your SQL. 
Although javax.sql.DataSource is by far the most commonly-used resource 
manager connection factory, you can have others including a mail or URL 


connection. 


in a bean’s business method: 

InitialContext ic = new 工 nitialContext(); 



七 his is ihc pavi o-f 

■the lookup that r^usi 

9° "the Vt) 


DataSource ds = (DataSource) ic. lookup (''java : comp/env/jdbc/CustomerDB ,r ) 
Connection conn = ds.getConnection(); 





va ： 






use ， V,as tVyf 

</resource_ref> 

</entity> 


<res-auth>Container</res-auth> 


<res-sharing-scope>Shareable</res-sharing-scope> 


<,r cs—shcl\rii 


same app ; usihA o 5hS，h 

wwL 吹 

dhMe 1 » . a c To 

sh 扣 ，仏 |d be u Mhsha ^ b|c ， 
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a bean’s environment 


Resource manager connection factory types 



You can’t put arbitrary types into the DD. For the four standard resource manager 
connection factories (five, if you count JMS topics and queues as two different 
types), you must use one of the following: 

<res - type>javax.sql.DataSource</res-type> 

<res - type>j avax.jms.QueueConnectionFactory</res-type> 
<res-type>javax.jms.TopicConnectionFactory</res-type> 



http://www.headfirst.com 


<res-type>javax.mail.Session</res-type> 


<res-type>javax.net.URL</res-type> 


Although these four are the only types standard to EJB 2.0, you can use the 
Connector architecture if you need access to other resources, like legacy systems. 
Connectors are out of scope for this book (and the exam), so you can relax. But 
you do need to know it’s out there, if you need it. 


Resource authorization 

Authentication to the EJB server itself is one thing, but chances are, the database 
has its own log-in scheme. A user might need a log-in name and password that is 
different from the one he uses to authenticate to the EJB server. 

As a Bean Provider, you can choose between two ways to give the resource 
manager (such as a database) the user’s log-in data. 

① <res-auth>Container</res-auth> 

Container authorization means the Deployer must configure the sign-on 
information for the resource manager. It’s completely vendor and resource-specific, 
and might mean that the deployer has to map between the principals and roles 
used in EJB security to whatever the resource manager needs. At the simplest 
level, the Deployer might specify a name and password thafll let anybody in. 

<res-auth>Bean</res-auth> 

Bean authorization means the programmer uses the overloaded version of 
getConnection() that takes a name and a password: 

Connection conn = ds.getConnection(userName , password); 
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mapping resources 


The complete resource mapping picture 


fake JNDI name: 

<resource-ref>CustDB</resource-ref> actual JNDI name: CustDatabase REAL database name: CustomerData 







In code, the Bean Provider does 
a JNDI lookup on a DataSource 
(which he uses to get a database 
connection). He doesn’t know the 
real JNDI name of the database 
(and he DEFINITELY doesn't 
know actual database name), so 
he makes one up. But he tells 
the deployer what he's done, 
by declaring a <resource-ref> 
element in the DD. 


Deployer maps the Bean 
Providers made-up <resource-ref> 
name to the actual JNDI name 
under which the DataSource is 
registered. 


The Sys-Admin (or someone in 
the operational environment 
configures the database into the 
server, and gives it a JNDI name. 


Where and how the mapping happens 


In the EJB In a vendor- In a Vendor- 

Deployment specific way specific way 



<resource-ref > database JNDI real database 

name 


this IS -the pairt iha-t s ih -the 

ahd pav-i you have 
to khow oh the exdrvt 


7 oull out V^oy/ {p do 

w a 代叫 70 UV 

PVod'At-t dotuwCir\-ba-t»oir> 


way ou 七 of -the sdopc o( 
a bean dcvclopcv-^ job 
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a bean’s environment 


EJB references 

(when a bean wants another bean) 


Beans who need other beans are the luckiest beans in the server. But 
remember, beans have to go through the home interface just like everybody 
else. If Bean A wants to do aJNDI lookup on Bean B’s home, we’ve got the 
same problem as always — what’s Bean B’s JNDI name? As a Bean Provider, 
you’re just making one up. At deploy time, the Deployer will map your 
fake coded name to the real JNDI name matching a bean of the type you 
specified in the DD. u 






in a bean’s business method 


InitialContext ic = new InitialContext(); ^ 

Object o = ic. lookup (''java: comp/env/ejb/AdviceGiver"); 

AdviceHome home = (AdviceHome) PortableRemoteObject.narrow(o, AdviceHome.class); 
Advice advisor = home.create(); 

// call methods on Advisor 


in the Deployment Descriptor 

<entity> 





<ejb-ref-name>ejb/AdviceGiver</ejb-ref-name> 


<ejb-ref-type>Session</ejb-ref-type> 





<home>headfirst. Advi ceHome< / home> 



<remote>headfirst. Advice</ remote 〉 




</entity 〉 
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EJB local references 


Use the <ejb-local-ref> tag if you want to look up the bean’s local home. 


<ejb-local-ref> 


丁 V>c sub-clewed avc 
鈍 “ 七 ^ lo6al 


<ejb-ref-name>ejb/AdviceGiver</ejb-ref-name> 
<ejb-ref-type>Session</ejb-ref-type> 

^ V r * . <lo6al-*^ omC> * - ^ <local-home>headfirst. AdviceHomeLocal</local-home> 

<lodal> 

mstcad <^o 滅:④ <local>headfirst. AdviceLocal</local> 

• o-f <vcwvo*tc> 

mstcad </ejb-local-ref> 



I understand the element names for <home> and 
<local-home>. Makes sense. But what’s up with <remote> 
and <local>? Shouldn’t it be <component> and <local- 
component>? 

A- 

You can run from your past, but you can’t hide. Before 
EJB 2.0, there was no concept of local interfaces. So the 
client view was always called Home and Remote. Although 
even that was an inconsistent name scheme, since both the 
home and the business method interface were Remote (as 
in java.rmi.Remote). But once local interfaces came on the 
scene, things got a bit more complicated."Let’s see... we can 
name the local home // local-home ,/ and then we’ll name the 
local remote "local-remote’: See the problem? So with EJB 
2.0, we stopped calling the business interface "the remote 
interface” and started calling it "the component interface ’： 
And now we call them "local component interfaces” and 
"remote component interfaces ’： 

Um, you still didn’t answer my question. How come 
the tag still says "remote” for the remote component 
interface and "local” for the local component interface? 

A- 

厂 Because of the past. Backward compatibility and 
all that. In EJB 1.1, the <ejb-ref> tags said <home> and 
<remote>, so they still do.The naming scheme is basically 
this: "The component interface is either local or remote. 

If the tag- doesn't explicitly say "home','then you’re 
talking about the component interface.These quirky little 
inconsistencies are just part of EJB’s charm. 


not be am e> mus * 
The <r . bea^f SSa9e - 

I: 

UPlnJN Dl.So d onnTtrZT et0l00k 


You do NOT specify the 
bean type in <ejb-ref> 

But is is SO tempting to think that you should. 
You put in ONLY the home and component 

lUce types for the bean, but not the 

exact class type of the bean! 
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Using <ejb-link> with EJB references 


If the Application Assembler sees that one bean’s EJB reference it 
to another bean in the same application, she should use the <ejb- 
link> to link the <ejb-ref> to another bean specified in the deployment 
descriptor. Think of <ejb-link> as a kind of “jump to this label” thing, 
where the value of the link matches the value of an <ejb-name> 
element somewhere else. 

Somewhere in the DD 

<entity> 

• •參 

<ejb-ref> 

<ejb-ref-name>ejb/AdviceGiver</ejb-ref-name> 
<ejb-ref-type>Session</ejb-ref-type> 
<home>headfirst. Advi ceHome< / home> 
<remote>headfirst. Advice</ remote 〉 
<ejb-link>AdviceEJB</ejb-link> 

</ejb-ref> 


</entity> 


Somewhere else 
in the DD 

<session> 


Tlic <c\b—lmk> MUST ma 七 "the 
value oT a” <cjb-hamc> (or some 
o*thcv- \y\ *tiiis PP (or a^otlicv 

PP \y\ the same JZE 6 app). 


<ejb-name>AdviceEJB</ejb-name> 


<ejb - linV values MOST 
match the value of some 
OTHER bean’s <ejb-na 3 ne> 

And remember- <e]h-rmie> 
is notog more than a label 
inilie DD. It doesn’t have 
to match the class name, 
interface name, JKDI name, 
or anyto^ else. It’S just 
tfie label in the DD for a 
particular bean. 

Nobody hut your co-worWs 
will care if you name your 
beans after, say, your pets. 


</session> 


又 <cjb-hamc> is just a label iiic W, (or 

o*thcv pav-ts o( PP h> v-c-fcv- *to. I^s ^o*t v-cal 

BEAN 乙 lass ov ahyiiiihg (unless you liappch h> 

make youv- cjb-hamc iiic same as {Me 匕 lass). 


< elb -name> must be unique within a means 

a single ejb-iar), but 心 ㈣— < e jb-name> 

But this does NOT mean all beans !l 1 ^ ■ fjj s wjth one DD per ejb-jar, and each of 

<ejb^link>JcustServi^^ 
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Resource environment references 
(think: JMS destinations) 


As a Bean Provider, you can look up two different kinds of resource-related 
things in JNDI: a resource manager connection factory reference, and a 
reference to something known as an administered object. The main difference 
is that a resource environment reference is to a thing you want, not the 
factory that gives you a connection to the thing you want. In other words, 
the administered object is the destination, whereas a resource manager 
connection factory reference is just the first step in getting what you really 
want (a connection). 

But today, just do a mental search and replace in your mind so that 
everywhere you see resource environment reference, you substitute JMS 
destination. Because that’s pretty much all you’ll use it for now. Yes, they 
could have called it “JMS destination reference”，but that would be too 
limiting for the future. Not to mention too clear, unambiguous, and 
meaningful to have any value whatsoever as a cognitive challenge. 


in a bean’s business method: 


InitialContext ic = new InitialContext(); 

Object o = ic• lookup (''java: comp/env/jms/NewCustomerQueue ’’）； 
javax.jms.Queue custQ = (javax.jms.Queue) o; 

// use the custQ 


in the Deployment Descriptor 

<entity> 


<resource-env-ref> 


f 

NO 丁 W 

JNPI 一 c A 



/ouV c how i^ d o( h 

that you h ccd h> leave 
java ： ^ P / Ch v/ ahd h 


<resource-env-ref-name>jms/NewCustomerQueue</resource-env-ref-name> 
<resource-env-ref-type>javax.jms.Queue</resource-env-ref-type> 


</resource-env-ref> 


</entity 〉 
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Provider and Application Assembler 



responsibility for the deployment descriptor 

Don’t worry about memorizing all of these now! It will make more 
sense as we get farther into the topics. For now, it’s OK for you to 
have just an overall concept of what each is responsible for. 


Bill puts m mos 七 by 
枷呼栋 a*b a 代 related 
todt *rn bean 

classes 



pu-ts 'm r^osiVj 七 
abou-t V^ov/ or btavss 

arc elated ^ m 

i\, t a 代 ad so^th^s 

sKe £.us*tow'»z^s kcSv' o 

•fov a ? av-t^ulav a 代沘 a 七 ，⑽. 


Bean Provider 


Application Assembler 


bean name 

fully-qualified name of bean class and 
home and component interfaces 

bean type (session, entity, etc.) 

re-entrancy (for entity beans only) 

state management for session beans 
(stateless or stateful) 

transaction demarcation type (bean or 
container) 

entity bean persistence management 
(bean or container) 

primary key class 

for CMP, abstract schema name, CMP 
fields, CMR relationships, finder and select 
queries. 

resource manager connection factory 
references 

environment entry declarations 

EJB references (local and remote) 

security role references 

for message-driven beans: destination, 
message selector, and acknowledgement 
mode. 


Modifications to Bean Provider information: 

■ values of environment 6ntri6S 

■ description fields (change or create) 

■ relationship name modifications 

■ message-driven bean message selector 
(may restrict, but not replace) 

Application Assemib/y information (all 

optional): 

■ binding enterprise bean references (i.e. 
linking one bean to another in the same 
ejb-jar or J2EE app) 

■ security roles (the recommended roles for 
clients of the beans.) 

■ method permissions: a relationship 
between security roles and methods of the 
home and component interface of the bean 

■ linking security role references to security 
roles 

■ security identity type: caller or run-as 

■ transaction attributes for methods of a CMT 
bean 
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the Deployer’s responsibilities 


Peployer responsibility for the 
Pcploymcwt Pcscriptor 



Deployer 


Modifications to Bean Provider information: 

■ ensure legal values for all environment entries 


Other tasks related to the deployment descriptor. All are done in 
a vendor-specific tool and NOT a part of the ejb-jar deployment 
descriptor: 


SECURITY 

■ assign of the security domain and principal realm to the app 

■ assign principals and/or groups to security roles, but NOT the secu¬ 
rity role references. 

■ principal delegation for inter-component calls (i.e. configuring the 
run-as principal). 


The Deployer 
does things 
using vendor- 
specific tools 

You might see a question about 
the deployer and things related 
to the deployment descriptor 
and think: 叮 he deployer isn’t 
supposed to touch things m the 
DD, so this can’t be his job. 

But... the deployer does have 
a lot of responsibilities related 
to things in the DD, so look 
carefully at the description of the 

task. 

For example, who maps 
security roles to security role 
references? The App Assembler. 
Who maps principals to security 
roles? The Doployor. 


RESOURCE MANAGER CONNECTION FACTORIES 

■ binding of resource manager connection factory references to an 
actual resource manager connection factory in the operational 
environment 

■ configuration sign-on info for container-authorized resource access. 

EJB REFERENCES 

■ ensure that all EJB references are bound to the homes of beans 
that exist in the operational environment 

■ ensure that the target bean is type-compatible with the types 
declared in the EJB reference. 

RESOURCE ENVIRONMENT REFERENCES (JMS topic or queue) 

■ ensure that all declared resource references are bound to objects 
that exist in the operational environment, and ensure that the target 
object is type-compatible with the declared type 
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Remembering who does what 




I have to 

integrate two or more 
beans (possibly from different 
vendors). So if Bean A uses the made- 
up security reference ''Employee” 
and Bean B has code using the made- 
up security reference u Minions ,, / 1 have 
to map them both to a single security 
role, ''Slaves". The Bean Provider 
declares the made-up name in the DD. 
That’s how he tells me what he's 
done in the code. 



Application 

Assembler 
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deploy-time customization 


Now let's look at the beaw's ruwtimc cwvirowmcwt 

We’re almost done with the bean’s world. Now that we’ve seen the bean’sspecial 
JNDI environment, we still have a few more little details on the bean’s runtime 
environment. Each of these is covered by the exam objectives, so don’t fall asleep 
now. We’re almost done! 


■ Guaranteed APIs 

You must which APIs are and are not guaranteed to be part of 
every EJB 2.0 container. For example, JMS is supported, JXTA is 
not. 


■ Guaranteed services 

You must know what is and is not guaranteed to be supported 
by every EJB 2.0 container. For example, transaction support is 
guaranteed, load-balancing is not. 


■ Structure of the ejb-jar 

Maybe this isn’t really a runtime environment thing, but we didn’t 
have another good place to stick it, and you have to know it. 

So here it is, just in case you don’t remember what we covered 
waaaaay back in chapter 1. For example, you must know that the 
an ejb-jar does not have a manifest, but MUST have a META-INF 
directory, and that directory MUST hold the deployment descriptor. 
Which, oh yes, MUST be named “ejb-jar.xml”. 


■ Programming restrictions 

If you want your bean to be portable to / compatible with any EJB 
2.0-compliant container, you must not do any of the things on 
the list, even if your vendor allows it (which the vendor may do 
unintentionally). 

And it’s not just for portability, but for safety. If you try to manage 
your own threads, for example, you’re stepping on the Container’s 
toes, and who knows what kind of mess you’ll end up with. You do 
not want to mess with the Container’s job. 

Just because your Container permits it, doesn’t make it right. And 
for the exam, you must know what’s restricted in the spec. 

If the exam asks if something is possible, and it’s one of the 
explicitly-restricted things in the spec, you must say NO, even if 
your vendor lets you do it. As far as the exam is concerned, if you 
can’t do it and remain portable, you can’t do it 
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Which APIs does EJ? 2.0 guarantee? 


Supported APIs 

■ Java 2 Standard Edition, v 1.3 (J2SE) 

■ JNDIAP11.2 

■ JTA 1.01 extension (the UserTransaction 
interface only) 

■ JDBC 2.0 extension 

■ JMS 1.02 extension 

■ JavaMail 1.1, sending mail only 

■ JAXP1.0 



You don’t have to memorize all of 
the exact version numbers 


The exam isn’t going to trick you on something 
as trivial as remember whether JavaMail is 1.1 or 1.2, 
or whether the JTA extension is 1.01 or 1.03. The only 
numbers you really need to know (besides the 2.0 in 
EJB 2.0!) are the JDBC 2.0 extension, and that only 
version 1.3 (not necessarily 1.4) of J2SE is guaranteed. 


㉗ W T is 

1-4, does not mM Versi °n 

guaranteed to L f not 
as of version 14 2SE platf °rm 


i^^rpen your pencil 


J2SE _ 

Without looking it up, write 
down what each of these 

JNDI 

APIs do. If you don’t know, 

JTA _ 

take a good guess based 
on what you know about 

JDBC 

EJB. 

JMS 

We’ll start you off by giving 
you the most difficult one. 

JavaMail 


JAXP 
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memorizing the APIs in EJB 2.0 



/\/\aWe 七似 k 


. rs a Picture that 
he J1SAS a^essenge^^ ve Java NAaW on top, 

anda — : 二 … 。⑽ ⑻. 

He de\wevs manage V ^ 

Transaction ^ ^ ^ 3 hour \ u nc • n 

he gets to stor y with the f :二 e x_) 

\ 一 


pKr 

EJB spec 

^rv/etsZsp m f AP/SJ/ke 

by the J 2 EE 二 ^ guaranteed 
the EJB spec ^ T n0t by 

^9ht trick you Q ° nes that 

JXTA 
JTS 

』ni NOT ^uav-ahieed as 

m ， UEJBZ.O.// 

jsp 
Servlets 




This delivery managed by 
Java Transaction API (JTA)! 


jPSc 

2,0 


Bob -takes a 13 iiowr 

1 冰乩 (J2£E 13) 


滅 ， Bob 醒 

^ A 納 Drt^ 

rtrih 


Java Messaging 
£cv-vidc (JMS) 


(JAXP) 


622 chapter 12 













a bean’s environment 


Some of the key，guaranteed 
services and behavior; 


■ Distributed transactions 


■ 


■ 


Thread-safety 

Container-managed persistence for entity beans 


■ A security domain and one principal realm (multiple realms 
is not guaranteed) 


■ 


Enforce client access security policies specified by the 
deployment descriptor and other deployment tools 

■ Implementation of the java:comp/env environment naming 
context provided to the bean 


■ 


Generation of classes that implement the home and 
component interfaces, and stub classes for remote objects. 

■ Implementation of the resource manager connection 
factory classes for resources configured with the server. 



Some things 
sound good 
but aren’t 
guaranteed! 

Everybody talks dbout their 
clustered, load-balanced, fault- 
tolerant system. Oh yeah, with fail¬ 
over, lazy-loading of entity data, 
and in-memory data caching. 

Although most J2EE vendors 
provide one or more of 
these capabilities, they aren’t 

guaranteed in the spec!! 

Be sure you know the difference 
between what is guaranteed 
and what is not. Look in the 
spec, under the sections 价 /ed 
<e Container Provider responsibility 
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the ejb-jar 


What MUST be iw aw ejb-jar? 



bea^s 




上 J 

<?xml veq^N 
sion="l■0^"" 

ejb-jar 

encoding 

="UTF_8〃？> 

<!DOCTYPE 
ejb-jar 

PUBInc. / 

ejb-jar.xml 


dcfloymch*t dcs^rip-tov- 


Structurc of aw ejb-jar 



ejb-jar 


〜classes /l/jUST 
be ih a div-c^"tov-y 
s i^iuyc ihsi 
tidies -the package 







ve 

: "i.o' r ~ 


encoding 

=〃UTF-8 ,, ?> 


You have to 
know what 
is NOT in the 
ejb-jar. 

You，re expected to know whats 
NOT in the ejb-jar file. Notice 
whaVs missing? The thing you 
expect to find in a JAR? Here’s 
a hint...ifs the thing that usually 
goes in the META-INF directory. 

Figure it out? The manifest! The 
manifest file is not required as 
of EJB 2.0. You CAN put one in, 
but it，s optional and usually not 
needed. 

You also must know what MUST 
not be in the ejb-jar: classes gen¬ 
erated by the container! Remem- 
ber，the container implements the 
home and component interface, 
and makes stubs if the interfaces 
are remote. This doesn’t happen 
until deployment... so they aren’t 
part of what the Bean Provider 
or Application Assembler put into 
their deliverable 一 the ejb-jar file. 


Advice.class 


011 0 1 


on o i^N 

1100 1 


1100 1 

0 100 0 


0 100 0 

0 111 


0 111 

0111 0 11 


0111 0 11 

00011 01 


00011 01 


ejb-jar.xml 、 

㈣ If 七 Atstr\^ 

MUST be 

a^a MUST 

加如 7 


AdviceHome.class AdviceBean.class 






ates 

avxd 

w cssay 


了 W bcah class file 






The naming 
convention is 
not required. 

Th f namin g convention for a bean 
is to put the component name as 
\ h u e component j n t e rf ace name 
then add ‘home’or ‘bean，to come 
up with the other two names. We 

f ron 9/y recommend that you fol- 

low,t; ,f mak es deployment much 
eas,er and lefs others read your 
code . But ^ not a requirement 
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a bean’s environment 


Programming restrictiows 

What to avoid in EJB if you want to guar¬ 
antee your bean can be deployed on ANY 
EJB 2.0-compliant server 


Servex Sod et 


^ ^cun y 
p y[ky 


I 汾 J/Wr te 

static ii、’J 


load a na ive 
Ukaiy 


AW r ,' oui put or 
keyl oard mt 


f riiucts 


cr at、or g a 

ck、s loaJ^r 


^°thlngV? h °at d 

Mr— 


ja aio ?ad age 




You really want to remember these programming restrictions.The best 
way to make that happen? Stop right now and think about each of 
these restricted things, and come up with one or more reasons for why 
the restriction exists. When you're done, turn to page 494 in the EJB 2.0 
spec, where these restrictions (and others) are described. 
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deploy-time customization 



Memorize THIS 


① 


Looking at the picture below, see if you 
can tell the story, putting in the API’s 
where they belong. We did one for you. 



He -takes a 13 iiouv 
lu^K-bvcak. 



② 



ejb-jar 


on o i\\ 
1100 1 
0 100 0 
0 111 
0111 0 11 
00011 01 


Advice.class 


Using the pieces below (and ONLY the pieces 
below) reassemble them into their correct 
configuration (drawing lines as needed). Draw 
your finished structure in the space at the right, 
and write the correct names on the directories, 
and name the .xml file. The bean is in the 
com.headfirst package. 



on o 
1100 1 
o 100 o 
0 111 
0111 0 11 
00011 01 


AdviceBean.class 



on o i\\ 
1100 1 
0 100 o 
0 111 
0111 0 11 
00011 01 


AdviceHome.class 



Pva>w the stvu£.*tuvc of 

七 he JAR -file 
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"TKcck Sxom 


Which APIs are guaranteed to be supported by EJB 2.0 containers? (Choose 
all that apply.) 

□ A. JAXP 

□ B. JNDI 

□ C. JXTA 

□ D. JDBC 

□ E. JMS 

What’s true about an enterprise bean’s environment? (Choose all that apply.) 

Q A. Environment entries can be unique for instances of the same 
enterprise bean type. 

口 B. Within a single EJB 2.0 container, an EJB can have multiple sets of 
environment entries. 

Q C. An EJB’s environment entry’s values can be modified by the EJB at 
runtime. 

口 D. Environment entry values may be primitives or wrapper types. 

Which APIs are guaranteed to be supported by EJB 2.0 containers? (Choose 
all that apply.) 

□ A. J2SE 1.3 

□ B. JAXB 1.0 

□ C. JAXR1.0 

□ D. JAXP 1.0 
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4 


Given a bean named 4 Customer’，and an environment entry named ‘lastName’: 
which code fragment (s) inside of the bean class would return the value of the 
environment entry? (Choose all that apply.) 

口 A. Context c = new SessionContext(); 

Context e = (Context) c. lookup (''java: comp/env"); 

String name = (String) e. lookup (''lastName); 

Q B. Context c = new InitialContext(); 

Context e = (Context) c. lookup (''java : comp/env/ 
Customer"); 

String name = (String) e • lookup (''lastName ,A ); 

□ C. Context e = new Lookup (''java: comp/env"); 

Context c = new InitialContext(e); 

String name = (String) c • lookup (''lastName"); 

Q D. Context c = new InitialContext (''Customer"); 

Context e = (Context) c. lookup (''java: comp/env"); 

String name = (String) e • lookup (''lastName ,A ); 

口 E. Context c = new InitialContext(); 

Context e = (Context) c. lookup (''java: comp/env"); 

String name = (String) e • lookup (''lastName"); 


When programming a session bean class which technique (s) should always be 
avoided to ensure bean portability across all EJB 2.0 containers? (Choose all 
that apply.) 

□ A. Using the java.net. Socket class. 

Q B. Using inner classes. 

口 C. Using the ‘final’ modifier for fields. 

[I D. Passing ‘this’ as an argument. 
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Which of the following are valid data types in a <env-entry-type 〉 element 
in a bean’s deployment descriptor? (Choose all that apply.) 

□ A. byte 

□ B. short 

口 C. ArrayList 

□ D. java. lang.Boolean 

□ E. java.lang.Character 


When programming EJBs which declaration (s) should be avoided to ensure 
bean portability across all EJB 2.0 containers? (Choose all that apply.) 

Q A. final int x; 

□ B. static int x; 

口 C. final static int x; 

Q D. final transient int x; 


Who is typically responsible for specifying finder and select queries in the 
bean’s deployment descriptor? 

Q A. The bean provider. 

Q B. The application assembler. 

口 C. The deployer. 

Q D. The system administrator. 

口 E. The server provider. 


Which deployment descriptor element(s) would be used when obtaining a 
JDBC connection? (Choose all that apply.) 

口 A. <ejb-ref> 

Q B. <ejb-link> 

口 C. <role-name> 

Q D. <env-entry 〉 

口 E. <resource-ref> 
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Who will typically merge multiple ejb-jar files into a single ejbjar file. 
Q A. The bean provider. 

Q B. The application assembler. 

口 C. The deployer. 

[I D. The system administrator. 

口 E. The server provider. 


Which deployment descriptor element(s) would be used by a bean provider to 
locate the home interfaces of other EJBs? (Choose all that apply.) 

口 A. <ejb-ref> 

□ B. <res-type> 

口 C. <env-entry> 

Q D. <role-name> 

口 E. <resource - ref> 


n 


Which are bean provider responsibilities concerning resource manager 
connection factory references? (Choose all that apply.) 

[I A. Configure resource managers in the EJB server. 

口 B. Configure sign-on information for the resource manager. 

口 C. Assign such a reference to the deployment descriptor. 

口 D. Creating a symbolic link to JNDI. 


13 


The ejb-jar file is considered to be part of the contract between which pairs? 
(Choose all that apply.) 

Q A. bean provider and system administrator 
Q B. bean provider and application assembler 
口 C. application assembler and deployer 
Q D. application assembler and system administrator 
Q E. deployer and system administrator 
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Which class files must be included, either directly or by reference, in every ejb- 
jar file? (Choose all that apply.) 

口 A. The enterprise bean class. 

Q B. The stub class for the EJBObject interface. 

[I C. The enterprise bean’s super classes. 

[1 D. AnyJ2SE classes used as arguments or return types. 

Which role is typically responsible for declaring the resource connection 
factory references in the deployment descriptor? 

口 A. bean provider 

Q B. application assembler 

口 C. deployer 

口 D. container provider 

Q E. system administrator 

What’s true about a legal ejbjar file? (Choose all that apply.) 

口 A. It must contain both a home interface and a component interface. 

Q B. The deployment descriptor is optional. 

Q C. It must contain anyJ2EE classes used by the bean. 

[I D. The enterprise bean class is optional. 


Which role would typically set up resource manager sign-on information? 
口 A. bean provider 
Q B. application assembler 
口 C. deployer 
口 D. container provider 
Q E. system administrator 
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Utoc^ Sxom /ia^en^ 


Which APIs are guaranteed to be supported by EJB 2 
all that apply.) 

^ A. JAXP 

W JNDI 

□ C. JXTA 

^ D. JDBC 

^ E. JMS 


(s_: W 


% 


What’s true about an enterprise bean’s environment? (Choose all that apply.) ( s ^c ： 今 10- 今 I 上 ) 

Q A. Environment entries can be unique for instances of the same 
enterprise bean type. 


4 


B. Within a single EJB 2.0 container, an EJB can have multiple sets of 
environment entries. 


Q C. An EJB’s environment entry’s values can be modified by the EJB at 
runtime. 

口 D. Environment entry values may be primitives or wrapper types. - S-tvmy 扣 d I’rappe 、 


3 


Which APIs are guaranteed to be supported by EJB 2.0 containers? (Choose (s_: 作-竹 
all that apply.) 

^ A. J2SE 1.3 

□ B. JAXB 1.0 

□ C. JAXR1.0 
^ D. JAXP 1.0 
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Given a bean named ‘Customer’，and an environment entry named ‘lastName ’， 
which code fragment(s) inside of the bean class would return the value of the 
environment entry? (Choose all that apply.) 





A. Context c = 
Context e = 
String name 


new SessionContext () ; - ScssiohCohtcxi is the same as J 咖 Qo^i 

(Context) c. lookup (''java: comp/env"); 

=(String) e. lookup (''lastName"); 


Q B. Context c = new InitialContext(); 

Context e = (Context) c. lookup (''java : comp/env/ 
Customer"); 


String name = (String) e • lookup (''lastName"); 

Q C. Context e = new Lookup (''java: comp/env"); 
Context c = new InitialContext(e); 


String name 

□ D. Context c = 
Context e = 
String name 

E. Context c = 


=(String) c. lookup (''lastName"); 

new InitialContext (''Customer") ; - ho avgurncht here 
(Context) c. lookup (''j ava: comp/env"); 

=(String) e. lookup (''lastName"); 

new InitialContext(); 


Context e = (Context) c • lookup (''java: comp/env"); 
String name = (String) e • lookup (''lastName"); 
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When programming a session bean class which technique (s) should always be 
avoided to ensure bean portability across all EJB 2.0 containers? (Choose all 
that apply.) 


□ A. 

□ B. 

□ C. 
^ D. 


Using the java.net. Socket class. 
Using inner classes. 

Using the ‘final’ modifier for fields. 
Passing ‘this’ as an argument. 


- 亡卜七 Sockets arc OK 
just ho*t a Sc\rvcvSofikc*t 


(S ? e6 ： 今竹-竹 55 
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Which of the following are valid data types in a <env-entry-type> element 
in a bean’s deployment descriptor? (Choose all that apply.) 

□ A. byte 

□ B. short 

Q C. ArrayList 

^ D. java.lang.Boolean , , . 丄 j 

一 or>ly av\d Strmy arc suffov-tcd 

aT e. java. lang.Character 


( s 〜 •仲 


1 


When programming EJBs which declaration (s) should be avoided to ensure 
bean portability across all EJB 2.0 containers? (Choose all that apply.) 




□ 

□ 

□ 


A. final int x; 

B. static int x; — should 3lso be 

C. final static int x; 

D. final transient int x; 



Who is typically responsible for specifying finder and select queries in the 
bean’s deployment descriptor? 

ar A. The bean provider. 

Q B. The application assembler. 

Q C. The deployer. 

Q D. The system administrator. 

Q E. The server provider. 


(^ 6 ： 作-柳 
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Which deployment descriptor element(s) would be used when obtaining a 
JDBC connection? (Choose all that apply.) 


Q A. <ejb-ref> 

Q B. <ejb-link> 

口 C. <role-name> 

Q D. <env-entry> 

E. <resource-ref> 


(s ? e6 ： 份 ) 
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Who will typically merge multiple ejb-jar files into a single ejb-jar file. 


□ 

af 


A. The bean provider. 

B. The application assembler. 


口 C. The deployer. 

Q D. The system administrator. 


口 E. The server provider. 


(s_ •㈣) 


Which deployment descriptor element(s) would be used by a bean provider to 
locate the home interfaces of other EJBs? (Choose all that apply.) 

A. <ejb-ref> 

□ B. <res-type> 

口 C. <env-entry> 

Q D. <role-name> 

口 E. 〈 resource-ref> 


(s_: 吵) 


Which are bean provider responsibilities concerning resource manager 
connection factory references? (Choose all that apply.) 


□ 

□ 

□ 


A. Configure resource managers in the EJB server. 

B. Configure sign-on information for the resource manager. 

C. Assign such a reference to the deployment descriptor. 

D. Creating a symbolic link to JNDI. 


(s_ 


The ejb-jar file is considered to be part of the contract between which pairs? 
(Choose all that apply.) 


aT 


A. bean provider and system administrator 

B. bean provider and application assembler 

C. application assembler and deployer 


Q D. application assembler and system administrator 
口 E. deployer and system administrator 


(s_: 州 ) 
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Which class files must be included, either directly or by reference, in every ejb- 
jar file? (Choose all that apply.) 

A. The enterprise bean class. 

Q B. The stub class for the EJBObject interface. 

zT c. The enterprise bean’s super classes. 

口 D. AnyJ2SE classes used as arguments or return types. atreadf be U : ^ \)d\) J 


Which role is typically responsible for declaring the resource connection 
^ factory references in the deployment descriptor? 

A. bean provider 


(s 〜 •松) 


Q B. application assembler 
口 C. deployer 
口 D. container provider 
Q E. system administrator 


16 


What’s true about a legal ejb-jar file? (Choose all that apply.) 

sT a. It must contain both a home interface and a component interface. 

Q B. The deployment descriptor is optional. 

口 C. It must contain anyJ2EE classes used by the bean. 

口 D. The enterprise bean class is optional. 


(s 〜 • 今⑽ 


17 


Which role would typically set up resource manager sign-on information? 


□ 

□ 




A. bean provider 

B. application assembler 

C. deployer 


口 D. container provider 
Q E. system administrator 


(s_ 
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Appenctix A ： 

Final Mock Exam 




A/ 

jc 兑办从 


Do NOT try to take this exam until you believe you’re ready for the real thing. If you take 
it too soon, then when you finally come back to it you’ll already have some memory of 
the questions, and it could give you an artificially high score. We really do want you to 
pass the first time. (Unless there were some way to convince you that you need to buy a 
fresh copy of this book each time you retake the exam...) 

To help defeat the “I remember this question” problem, we’ve made this exam just a little 
harder ihan the real exam, by not telling you how many answers are correct for each 
of our questions. Our questions and answers are virtually identical to the tone, style, 
difficulty, and topics of the real exam, but by not telling you how many answers to choose, 
you can’t automatically eliminate any of the answers. It’s cruel of us, really, and we wish 
we could tell you that it hurts us more than it hurts you to have to take the exam this way. 
(But be grateful — until a few years ago, Sun’s real Java exams were written this way, 
where most questions ended with “Choose all that apply .”） 

Most exam candidates have said that our mock exams are a little more difficult than the 
real SCBCD, but that their scores on our exam and on the real one were very close. This 
mock exam is a perfect way to see if you’re ready, but only if you: 

1) Give yourself no more than two hours to complete it, just like the real exam. 

2) Don’t look anywhere else in the book while you’re taking the exam! 

3) Don’t take it over and over again. By the fourth time, you might be getting 98% and yet 
still not be able to pass the real exam, simply because you were memorizing our exact 
questions and answers. 

4) Wait until after you finish the exam to consume large quantities of alcohol or other 
mind-altering substances (Ben and Jerry’s™ Fudge Brownie, Red Bull™, Frosted 
Flakes™ cereal to name a few of the more deadly ones). 
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1 Which are benefits of EJB 2.0? (Choose all that apply.) 

Q A. MDBs survive server crashes. 

口 B. Representations of a single entity can be shared among multiple cli¬ 
ents. 

口 C. Support for nested transactions. 

[I D. Dynamic service discovery. 

口 E. Declarative isolation level settings. 

^ Which methods are directly invoked by the client? (Choose all that apply.) 

□ A. e jbPassivate () 

Q B. business methods 

□ C. setSessionContext() 

Q D. newlnstance() 

□ E. create() 


3 


Which method(s) can be found in the EJBHome interface? (Choose all that 
apply.) 

Q A. remove (Handle handle) 

口 B. remove (Object primaryKey) 

Q C. getHandle() 

Q D. none of the above 
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Which method(s) can be run by a CMP bean in the pooled state? (Choose all 
that apply.) 

□ A. ejbLoad () 

□ B. ejbFind () 

□ C. ejbStore () 

□ D. ejbCreate() 

口 E. Business method 

□ F. e jbHome () 

What’s true about message-driven beans? (Choose all that apply.) 

口 A. All calls to a message-driven bean instance must be serialized. 

Q B. The container guarantees that messages will be processed in the order 
in which they are received. 

[I C. The bean’s ejbCreate () method must take a single argument of type 

javax. jms. Message. 

Q D. The bean provider uses the deployment descriptor to indicate whether 
instances of the bean class are intended for topics or queues. 

What’s true about an enterprise bean’s environment? (Choose all that apply.) 

Q A. Before a bean can access its environment entries, the bean must first 
obtain the naming context using a SessionContext object. 

口 B. Only the bean provider can set an environment entry value. 

[I C. A bean’s environment entries can be stored only in 
' j ava: comp/env^ or one of its subcontexts. 

[I D. Every environment entry lookup in a bean’s code must have a matching 
<env-entry> element in the bean’s deployment descriptor. 
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What’s true about security roles in EJBs? (Choose all that apply.) 

口 A. Security roles are defined in the deployment descriptor using <security- 
role> elements. 

Q B. Security roles are scoped to the instance level 
口 C. Many methods can be mapped to a single security role. 

口 D. A method can appear in only one security role. 
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An EJB 2.0 container must support at least a subset of which APIs? (Choose all 
that apply.) 


□ A. JTA1.0.1 

□ B. JDBC 2.0 

□ C. JMS 1.0.2 

□ D. JAX-RCP 1.0 


Which statements concerning stateless session beans are true? (Choose all that 
apply.) 

Q A. They can use bean-managed transaction demarcation. 

口 B. They must have one no-argument create method. 

Q C. A single instance can support concurrent calls. 

Q D. They must extend javax.ejb.SessionBean 


10 


What capability exists in ONLY ONE of the two (but not both)? 
- an entity object’s remote component interface 
- an entity object’s local component interface 
(Choose all that apply.) 

口 A. Removing the object. 

Q B. Obtaining the object’s handle. 

口 C. Invoking business methods. 

口 D. Obtaining the object’s primary key. 


When creating a CMP entity bean, which method(s) are optional? (Choose all 
that apply.) 

□ A. ejbLoad () 

□ B. ejbCreate () 

□ C. ejbRemove () 

□ D. ejbSelect() 

□ E. ejbPassivate() 

□ F. setEntityContext () 
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Which method(s) can be called on a bean in the pooled state? (Choose all 
that apply.) 

□ A. ejbFind () 

□ B. ejbLoad () 

□ C. ejbStore () 

□ D. ejbSelect() 

□ E. ejbPassivate() 

What’s true about the lifecycle of a message-driven bean? (Choose all that ap- 

p!y-) 

Q A. When the the onMessage method completes, the container will typi¬ 
cally call ejbRemove. 

Q B. The onMessage () method can throw application exceptions. 

口 C. Message-driven beans can run only with CMT demarcation. 

Q D. The getRollbackOnly () method can be called only from the 
onMessage method. 


Which statement(s) concerning message-driven bean classes are true? 
(Choose all that apply.) 

Q A. They must implement, directly or indirectly, javax• jms .Message. 

Q B. They must have a public constructor that takes a single argument of 
type javax • jms .Message. 

口 C. Implementing the finalize () method is allowed. 

口 D. Implementing the ejbCreate () method is optional. 

口 E. The class must not be declared ‘final’. 

Within the deployment descriptor’s <ejb-local-ref> element, which ele¬ 
ments are optional? (Choose all that apply.) 

Q A. <local> 

Q B. <ejb-link> 

口 C. <local-home> 

Q D. <description> 

口 E. <ejb-ref - name> 

□ F. <ejb-ref-type> 
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What’s true about resource manager connection factories? (Choose all that 
apply.) 


口 The <res - sharing- scope> deployment descriptor element is used to 
indicate whether connections to a resource manager are shareable 
across multiple EJBs in an application. 

Q B. The <res-sharing-scope> deployment descriptor element contains 

the <resource-ref> element. 

Q C. All of a bean’s resource manager connection factory references are 
declared in a single <resource-ref> element, using 
<res-ref-name> elements to distinguish them. 

Q D. By default, connections to a given resource manager are shareable 
across multiple beans in an application. 


What’s true about security roles referenced from an EJB’s code? (Choose all 
that apply.) 


Q A. In the deployment descriptor, such references are contained in the 

<security-role-ref> element. 

口 B. The <security-role> element includes the <security-role- 

ref > element. 

口 C. Within the <security-role-ref> element, the <role-name> 

element’s value is the same as the argument for the bean’s invocation 

of the isCallerlnRole method. 

口 D. The <role-link> element is used to link two 

<security-role-ref> elements. 
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What’s true about the client’s view of security? (Choose all that apply.) 

Q A. A transactional client cannot change its principal association within a 
transaction. 

Q B. A session bean’s client cannot change its principal association for the 
duration of the communication with the session object. 

口 C. Transactional requests within a single transaction cannot arrive from 
multiple clients. 

Q D. None of the above. 
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When programming an entity bean class which technique (s) should be 
AVOIDED to ensure bean portability across all EJB 2.0 containers? (Choose all 
that apply.) 

[I A. Changing a thread’s priority. 

口 B. Using the reflection API. 

口 C. Using wrapper classes. 

Q D. Using static nested classes. 


When programming a message-driven bean class which technique (s) should 
be avoided to ensure bean portability across all EJB 2.0 containers? (Choose 
all that apply.) 

口 A. Using Swing APIs for a GUI. 

口 B. Using the ‘transient’ modifier. 

Q C. Using native libraries. 

口 D. Reading file descriptors.. 

What is required of the container when it passivates a stateful session bean? 

Q A. The bean’s instance state will always undergo Java programming lan¬ 
guage Serialization. 

Q B. It must save all of the bean’s instance field state regardless of the fields’ 
modifiers. 

Q C. It must save any references to the bean’s SessionContext object. 

口 D. It must save all non-null transient variables. 


Which capabilities are defined in the j avax. e jb. E JBLocalOb ject inter¬ 
face? (Choose all that apply.)? 

Q A. Remove an entity object. 

Q B. Obtain an entity object’s primary key. 

Q C. Obtain a local home interface for the entity object. 

口 D. Obtain a remote component interface for the entity object. 

口 E. Expose the methods of the j avax. ejb. EntityBean interface to the 
client. 
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What’s true about ejbSelect methods? (Choose all that apply.) 

Q A. They can be exposed to the client. 

Q B. They can return only EJBObjects or EJBLocalObjects. 

口 C. They can be invoked only by a bean in the ready state. 

Q D. They must be associated with a query element in the deployment de¬ 
scriptor. 


Z4 


Which methods can NEVER be successfully invoked from a message-driven 
bean? (Choose all that apply.) 

Q A. isCallerlnRole() 

□ B. getE JBHome () 

□ C. getRollbackOnly() 

□ D. setRollbackOnly() 

□ E. getCallerPrincipal() 


zs 


Which role is typically responsible for adding <ejb-link> elements to an EJB’s 
deployment descriptor? 

口 A. bean provider 
Q B. application assembler 
口 C. deployer 
口 D. container provider 
Q E. system administrator 


Z6 


In which of the following methods can a stateless session bean invoke the 
isCallerlnRole () method in order to perform a security check? (Choose 
all that apply.) 


□ A. ejbCreate () 

□ B. ejbRemove () 

□ C. setSessionContext() 

Q D. None of the above 
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Which two are typically responsible for creating ejb-jar files? (Choose two.) 
口 A. The bean provider. 

口 B. The application assembler. 

口 C. The deployer. 

口 D. The system administrator. 


Which of the following stateless session bean container callback method (s) 
takes an argument? (Choose all that apply.) 

口 A. ejbRemove 

□ B. ejbCreate 

□ C. ejbCreate 

□ D. ejbPassivate 

□ E. setSessionContext 


Which of these can never be called on a SessionContext interface? (Choose all 
that apply.) 

□ A. getE JBHome () 

□ B. getEJBObject() 

□ C. getEJBTransaction() 

Q D. isCallerlnRole () 

□ E. getUserTransaction() 

What’s true about an entity bean’s remote component interface? (Choose all 
that apply.) 

Q A. If a client attempts to invoke a method on an entity that does not exist, a 

java, rmi. NoSuchRemoteOb j ectException will be thrown. 

Q B. It must extend javax. e jb. E JBHome 
Q C. Its methods must declare java. rmi. RemoteException 
口 D. It defines a remove (Handle handle) method. 
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Which are true about finder methods in an entity bean’s local home interface? 
(Choose all that apply.) 

Q A. They can have any legal Java name. 

□ B. They must all declare j avax. ejb. FinderException. 

口 C. They can optionally declare j ava. rmi. RemoteException. 

口 D. The findByPrimaryKey method can be overloaded. 

Q E. The findByPrimaryKey method’s return type must be the bean’s local 
component interface. 

口 F. A method called “findXXX” must have the bean’s local component 
interface as its declared return type. 
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Which are true for a message-driven bean? (Choose all that apply.) 

Q A. The Deployer uses the deployment descriptor to determine whether a bean 
is intended for a Queue or a Topic. 

Q B. The class must be declared final. 

口 C. The class must define one e jbRemove() method. 

Q D. The class can have overloaded e jbCreate () methods. 

Q E. The class must define a no-argument onMessage method. 


33 

<entity> 

<ejb-name>Payroll</ejb-name> 
<security—role-ref> 

<role-name>clerk</role-name> 


Given the following subset of a deployment descriptor: 


</security-role-ref> 

</entity> 

Which code snippet(s) makes a legal security check? (Choose all that apply.) 

口 A. context • isCallerlnRole (''Payroll ”）； 

Q B. context • isCallerlnRole ( 、 'clerk 〃）； 

口 C. context. isCallerlnRole (''Payroll. clerk 〃）； 

口 D. context • isCallerlnRole ( 、 'Payroll/clerk 〃）； 
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Which are valid local home interfaces for a stateful session bean? (Choose all 
that apply.) 

Q A. public interface TestBean implements 
javax.ejb.EJBLocalHome { 

void create() throws CreateException; 

} 

Q B. public interface TestBean extends 
javax.ejb.EJBLocalHome { 

TestBeanLocal ejbCreate() throws CreateException; 

} 

Q C. public interface TestBean extends 
javax.ejb.EJBLocalHome { 

TestBeanLocal create() throws CreateException; 

} 

口 D. public interface TestBean extends 
javax.ejb.EJBLocalHome { 

TestBeanLocal create() throws CreateException , 
RemoteException; 

} 

Q E. public interface TestBean extends 
javax.ejb.EJBLocalHome { 

TestBeanLocal create() throws LocalException; 


Which methods can be called by a bean provider? (Choose all that apply.) 

Q A. remove () 

□ B. ejbCreate () 

□ C. afterBegin() 

口 D. getCallerPrincipal() 

□ E. ejbPassivate() 
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Who will typically specify whether a bean is re-entrant in the bean’s deploy¬ 
ment descriptor? 

Q A. The bean provider. 

Q B. The application assembler. 

口 C. The deployer. 

Q D. The system administrator. 


Which statements about stateful and stateless session beans are true? 

(Choose all that apply.) 

Q A. Only stateful session beans support transactions. 

Q B. Only stateful session beans can be passivated. 

Q C. Only stateful session beans have a ' setSessionContext A method. 

口 D. Both stateful and stateless session beans can support overloaded 

'ejbCreate' methods. 

口 E. Both stateful and stateless session beans can implement the 

javax. ejb. SessionSynchronization interface. 

Q F. Both stateful and stateless session beans can have instance variable state. 


38 Which must be included in every ejbjar file? (Choose all that apply.) 

Q A. The stub for the EJBHome interface, either directly or by reference. 
Q B. The JAR Manifest file. 

口 C. A deployment descriptor. 

Q D. TheJNDI context. 

口 E. The EJB’s home interface, either directly or by reference. 
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Which method (s) are declared in the javax.ejb.EJBHome interface? (Choose 
all that apply.) 

□ A. create() 

□ B. lookup() 

□ C. getHandle() 

□ D. getHomeHandle() 

□ E. setSessionContext() 
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How manyjavax.ejb.EJBLocalHome interface methods can be called without 
an exception, from a session bean client? 

□ A. 0 

□ B. 1 

□ C. 2 

□ D. 3 

□ E. 4 


Which of the following, if called, always have the same transaction context as a 
session bean’s business methods? (Choose all that apply.) 

口 A. constructor 

□ B. setSessionContext() 

□ C. afterBegin() 

□ D. afterCompletion() 

□ E. beforeCompletion() 


Given a stateful session bean with container-managed transaction demarcation, 
from which methods can you access another bean? (Choose all that apply.) 

□A. setSessionContext() 

□ B. ejbCreate () 

□ C. afterBegin() 

□ D. beforeCompletion() 

□ E. afterCompletion() 


Which deployment descriptor element(s) can optionally specify cascade-delete 
functionality? (Choose all that apply.) 

Q A. <ejb-relation> 

Q B. <abstract-schema-name> 

口 C. <ejb-relationship-role> 

Q D. <relationship-role-source> 
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What’s true about cascade-delete? (Choose all that apply.) 

[I A. It is declared in the ejbRemove () method. 

Q B. When a cascade-delete enabled bean is deleted, it causes all of the 
beans with relationships to it to be automatically deleted too. 

口 C. It can be specified for one-to-one, one-to-many, or many-to-many rela¬ 
tionships. 

Q D. A cascade-delete enabled bean is automatically removed when any 
“multiplicity of one” bean with which it is related is removed. 


45 


Which method(s) from the EntityContext interface can be invoked, regardless 
of transaction context? (Choose all that apply.) 


□ A. getE JBHome () 

□ B. getEJBObject() 

□ C. setRollbackOnly() 

□ D. getRollbackOnly() 



What’s true about an entity bean’s primary key? (Choose all that apply.) 

Q A. Primary key fields must be cmp-fields. 

Q B. Setter methods for fields associated with a primary key must not be 
exposed through a client view. 

口 C. If two entity objects have the same home and the same primary key, 
they are considered identical. 

口 D. The getPrimaryKey () method can be invoked on references to only 
remote home interfaces, not local home interfaces. 


4 ? 


Which interface (s) are used by the bean provider to perform BMT demarca¬ 
tion? (Choose all that apply.) 

口 A. javax.transaction.Transaction 

Q B. javax.transaction.UserTransaction 

Q C. j avax.transaction.Synchronization 

口 D. javax.transaction.TransactionManager 


650 appendix A 






appendix A final mock exam 


Which of the following are legal EJB QL queries? (Choose all that apply.) 

□ A. SELECT c 

FROM Customer c 

□ B. SELECT (OBJECT) c.name 

FROM Customer c 

□ C. SELECT OBJECT c 

WHERE Customer c 

□ D. SELECT OBJECT (c) 

FROM Customer c 

Q E. SELECT c.name 

FROM Customer c 


Which are true about transactions in EJB 2.0? (Choose all that apply.) 

口 A. Only one database can be updated within a single transaction. 

Q B. Entity beans with BMT demarcation must use the setStatus method 
instead of the setRollbackOnly method. 

[I C. Entity beans with BMT demarcation must use the getStatus method 
instead of the getRollbackOnly method. 

Q D. BMT demarcation should be used when beans access resource manag¬ 
ers that do not support transactions. 

口 E. The ‘SessionSynchronization’ interface can be used only by stateful 
session beans. 


To ensure bean portability, which transaction attributes should be used on the 
business methods in the component interface of an entity bean using CMP? 
(Choose all that apply.) 

[I A. NotSupported 

Q B. Required 

口 C. Supports 

Q D. RequiresNew 

Q E. Mandatory 

Q F. Never 
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Which of the following exceptions would cause a bean to be discarded by the 
container? (Choose all that apply.) 

□ A. javax. ejb. ObjectNotFoundException 

□ B. javax.ejb.CreateException 

□ C. j avax.ejb.NoSuchEntityException 
Q D. javax.ejb.FinderException 

口 E. j avax. ejb. RemoveException 



In which cases should the container log an exception thrown by a business 
method of a CMT demarcated bean? (Choose all that apply.) 


口 A. If the method runs with an unspecified transaction context and throws 
a system exception. 

Q B. If the method runs with an unspecified transaction context and throws 
an application exception. 

口 C. If the method runs with a RequiresNew context and throws a system 
exception. 

Q D. If the method runs with a Required context and throws a system excep¬ 
tion. 


口 E. If the method runs with a RequiresNew context and throws an applica¬ 
tion exception. 

Q F. If the method runs with a Required context and throws an application 
exception. 


53 


Which session bean component interface method(s) can be called successfully, 
by a local client? (Choose all that apply.) 


Q A. remove () 

□ B. getHandle() 

□ C. is Identical () 

□ D. getEJBHome () 
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In what scenario (s) can a bean’s business method call the isCallerlnRole () 
method of the SessionContext interface? (Choose all that apply.) 

Q A. A stateful session bean with container-managed transaction demarca¬ 
tion. 

Q B. A stateless session bean with container-managed transaction demarca¬ 
tion. 

Q C. A stateful session bean with bean-managed transaction demarcation. 

口 D. A stateless session bean with bean-managed transaction demarcation. 

Q E. None of the above. 


When creating an entity bean using container-managed persistence, which can 
be accessed through the bean’s remote component interface? (Choose all that 
apply.) 

口 A. Accessor methods for the relationship fields. 

口 B. The local interface of the entity bean. 

口 C. The bean’s business methods. 

Q D. The collection classes used for container-managed relationships. 

[I E. Accessor methods for the persistent fields. 

Given the container-managed, one-to-one, bidirectional relationship: 

Foo < - > Bar 

And the object relations: 

fl <---> bl 
f2 <——> b2 

Which boolean expression will be true after the following code runs: 

b2 . setFoo (bl.getFoo ()); 

(Choose all that apply.) 


□ 

A. 

f1.getBar()== 

null 

□ 

B. 

b2.getFoo()== 

null 

□ 

C. 

f2.getBar()== 

null 

□ 

D. 

none of the above 
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What’s true about an entity bean’s identity? (Choose all that apply.) 

Q A. If two entity object references are compared using the == operator, the 
container provider is not required to produce consistent results. 

Q B. If two entity object references are compared using the equals () 

method, the container will return true if the two entity objects have the 
same primary key. 

口 C. If two entity object references are compared using the is Identi¬ 
cal ()method, the container will return true if the two entity objects 
have the same primary key. 

Q D. None of the above statements are true. 


Given CMP beans CustomerBean, OrderBean, and LineltemsBean with the 
following relationships: 

CustomerBean (1) < — > OrderBean (n) 

OrderBean (1) < — > LineltemsBean (n) 

Which will return a set of customers that have orders? (Choose all that apply.) 

Q A. SELECT Customer 
FROM Order 

□ B. SELECT DISTINCT Customer 

FROM Order 

Q C. SELECT o.custnum 

FROM Order o, Customer c 
WHERE c.custnum = o.custnum 

□ D. SELECT OBJECT (c) 

FROM Customer c, Order o 
WHERE c.custnum = o.custnum 

□ E. SELECT DISTINCT OBJECT (c) 

FROM Customer c, Order o 
WHERE c.custnum = o.custnum 
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Given: 


Method-1 (Tx-1) --> Method-2 (Tx-1) - > Method-3 (Tx-l) 

\--> Method-4 (Tx—2) 


If the calling method is on the left side of an arrow, and the called method on 
the right, which set of transaction attributes will support the transaction scope 
specified? (Choose all that apply.) 

Q A. Ml = Never 

M2 = Supports 
M3 = Required 
M4 = Require sNew 

Q B. Ml = Required 
M2 = Supports 
M3 = Mandatory 
M4 = Require sNew 

口 C. Ml = RequiresNew 
M2 = Require sNew 
M3 = Supports 
M4 = Require sNew 

Q D. Ml = Required 
M2 = Mandatory 
M3 = Supports 
M4 = Supports 


Given the EJB QL expression: 

p.discount NOT BETWEEN 10 AND 15 


Which expression is equivalent? 

Q A. p.discount < 10 OR p.discount > 15 

□ B. p.discount <= 10 OR p.discount > 15 

□ C. p.discount < 10 OR p.discount >= 15 

□ D. p.discount <= 10 OR p.discount >= 15 
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When a business method in an entity bean calls the getRollbackOnly () 
method, which transaction attribute settings could cause the container to 
throw an exception? (Choose all that apply.) 

[I A. NotSupported 
Q B. Required 
口 C. Supports 
Q D. RequiresNew 
Q E. Mandatory 
Q F. Never 


62 


Which of the following is performed by the container if a message-driven bean 
does not complete its transaction before the end of the onMessage() method? 
(Choose all that apply.) 

口 A. Log an application error. 

Q B. Roll back the started transaction. 

[I C. Discard the instance of the bean. 

口 D. Throw an exception. 
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From which class (es) can application exceptions extend? (Choose all that ap- 

p!y-) 

□ A. java.lang.Exception 

Q B. j ava.lang.RuntimeException 
口 C. j ava. rmi. Remo teExcept ion 

□ D. javax.ejb.CreateException 


64 


What’s true about application exceptions? (Choose all that apply.) 
Q A. They are intended to be handled by the system administrator. 
Q B. They should report system level problems. 

口 C. They cause automatic marking of transactions for rollback. 

□ D. They must not extend j ava. lang. RuntimeException 
口 E. They may extend java, rmi. Remo teExcept ion 
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Which cases can cause a session bean instance to be destroyed without the 
container calling ejbRemove () ? (Choose all that apply.) 

Q A. A transaction is rolled back on a stateful session bean with container- 
managed transaction demarcation. 

Q B. A system exception is thrown from a business method. 

口 C. An inactive client is timed out while the bean is in a passivated state. 

口 D. The client invokes the remove method while the bean is in a transac¬ 
tion. 


Which deployment descriptor element(s) are used to specify a Collection 
interface? (Choose all that apply.) 

Q A. <ejb-name> 

Q B. <cmr-field> 

□ C. <ejb-relation> 

Q D. < canr-field-type> 

Q E. <abstract-schema - name> 


If a bean catches a checked exception, from which it cannot recover, what 
should it do? (Choose all that apply.) 

□ A. If the client is remote, throw a java, rmi. Remo teExcept ion. 

Q B. Print a stack trace. 

口 C. Regardless of the client, throw a javax. ejb. EJBException. 

口 D. Regardless of the client, propagate the same exception to the contain¬ 
er. 

Which are requirements for a CMP entity bean class? (Choose all that apply.) 
Q A. All e jbSelect () methods must be declared as abstract.. 

Q B. The class must NOT define an e jbCreate method. 

口 C. The e jbPostCreate methods are implemented by the container. 

口 D. Helper methods must NOT be implemented in the bean class. 

口 E. Methods starting with ‘e jbFind’ must not be implemented. 
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Which are valid deployment descriptor segment(s) to define a cmr-field? 
(Choose all that apply.) 

Q A. <ejb-relationship-role> 

<!—— assume mandatory ejb-relationship-role elements 
inserted here --> 

<cmr-field> 

<onr-field-type>java. util. Collec tion</ cmr-field- type> 
</cmr-field> 

</ejb-relationship-role> 

Q B. <ejb-relationship-role> 

<!-- assume mandatory ejb-relationship-role elements 
inserted here ——> 

<cmr-field> 

<cmr-fie Id-name>l ine I tems< / cmr - fie Id-name> 
<onr-field-type>java. util. Collec tion</ cmr-field- type> 
</cmr-field> 

<ejb-relationship-role> 

Q C. <relationship-role-source> 

<!-- assume mandatory relationship-role-source ele¬ 
ments inserted here --> 

<cmr - field 〉 

<cmr-field-type>java. util. Collec tion</ cmr-field- type> 
</cmr-field> 

</relationship-role-source> 

Q D. <relationship-role-source> 

<!—— assume mandatory relationship-role-source ele¬ 
ments inserted here --> 

<cmr - field 〉 

<cmr-fieId-name>line I tems</ cmr-fieId-name> 
<onr-field-type>java. util. Collec tion</ cmr-field- type> 
</cmr-field> 

</relationship-role-source> 
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What’s true about a remote client’s view of exceptions received from an entity 

bean? (Choose all that apply.) 

Q A. If the container marks a transaction for rollback, the container will 

always issue a javax. transaction. TransactionRolledbackExce 
ption exception. 

□ B. If the client receives a javax • transaction. TransactionRolled 
BackException, the container guarantees that that transaction will 
never commit. 

口 C. A javax•transaction.TransactionRequiredException excep¬ 
tion, informs the client that the bean needed to be called within the 
context of a transaction. 

Q D. If the container discovers that a requested bean no longer exists, it will 
always throw the javax.ejb.NoSuchObjectEntityException. 
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"TKodz Sxom /ia^uen^ 



Which are benefits of EJB 2.0? (Choose all that apply.) 
Q A. MDBs survive server crashes. 




B. Representations of a single entity can be shared among multiple cli¬ 
ents. 


(s_: _ 


Q C. Support for nested transactions. 

Q D. Dynamic service discovery. 一 Tha*t’s a Jm'i 七 iVnr^ 
Q E. Declarative isolation level settings. 


z 


Which methods are directly invoked by the client? (Choose all that apply.) 


□ 


□ 

□ 




A. ejbPassivate () - invoked by *thc Cojr\*ta*mc\r 

B. business methods 

C. setSessionContext() 

D. newlnstance () - invoked by the Cojrrtamev 

E. create() 


3 


Which method(s) can be found in the EJBHome interface? 
apply.) 

A. remove (Handle handle) 

^ B. remove (Object primaryKey) 

□ C. getHandle() 一 is *m 
Q D. none of the above 


(Choose all that 
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4 


5 


6 


7 


Which method(s) can be run by a CMP bean in the pooled state? (Choose all 
that apply.) 


I ⑹ 


□ A. 

txT b. 

□ c. 

□ D. 


ejbLoad () 
ejbFind() 
ejbStore () 
ejbCreate () 


一 The bedh docs^-t leave {\\t fool -Po\r 
home and -fmdev methods 


□ E. 
^ F. 


Business method 

ejbHome() 


What’s true about message-driven beans? (Choose all that apply.) 

^ A. All calls to a message-driven bean instance must be serialized. 


( s …抓 训如 ^ 


Q B. The container guarantees that messages will be processed in the order 
in which they are received. 

Q C. The bean’s ejbCreate () method must take a single argument of type 

javax • jms .Message. 

^ D. The bean provider uses the deployment descriptor to indicate whether 
instances of the bean class are intended for topics or queues. 


What’s true about an enterprise bean’s environment? (Choose all that apply.) 


must d ir>o— 

-takes -tKc 

message as i-ts av-^umc^-t 


(s ? e6 ： 价-仲 


Q A. Before a bean can access its environment entries, the bean must first 
obtain the naming context using a SessionContext 

口 B. Only the bean provider can set an environment entry value. 


if 


)ean must nrst 


ov 


C. A bean’s environment entries can be stored only in — 如^七 a j^p ( ^ 

'java: comp/env^ or one of its subcontexts. dike Scss'.o^Co^c^) 

D. Every environment entry lookup in a bean’s code must have a matching 

<env-entry> element in the bean’s deployment descriptor. — o-bhery/ise 七 he Code, y/ould have 
_ yuybWq bo look 


What’s true about security roles in EJBs? (Choose all that apply.) 

^ A. Security roles are defined in the deployment descriptor using <security- 
role> elements. 


(s ? e6 ： W - 州 ) 


Q B. Security roles are scoped to the instance level 
^ C. Many methods can be mapped to a single security role. 
口 D. A method can appear in only one security role. 
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An EJB 2.0 container must support at least a subset of which APIs? 
that apply.) 


aT A. JTA 1.0.1 
2^ B. JDBC 2.0 
^ C. JMS 1.0.2 
□ D. JAX-RCP 1.0 


(Choose all 


(s ? e6 ： 恨 W 


9 


Which statements concerning stateless session beans are true? (Choose all that 
apply.) 

^ A. They can use bean-managed transaction demarcation. 

^ B. They must have one no-argument create method. 

Q C. A single instance can support concurrent calls. 

Q D. They must extend javax.ejb.SessionBean - : ) 


10 


What capability exists in ONLY ONE of the two (but not both)? 
- an entity object’s remote component interface 
- an entity object’s local component interface 
(Choose all that apply.) 

口 A. Removing the object. 

^ B. Obtaining the object’s handle. )r> 0 *t -fov loddl m*tcv*-f3dcs 
口 C. Invoking business methods. 

口 D. Obtaining the object’s primary key. 


11 


When creating a CMP entity bean, which method(s) are optional? (Choose all 
that apply.) 


(和:门1-门今) 


= A ejbLoad() , a ^ 

ST B. ejbCreate() - 

□ C. ejbRemove () 

^ D. ejbSelect() 

□ E. ejbPassivate() 

□ F. setEntityContext () 
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Which method(s) can be called on a bean in the pooled state? (Choose all 
that apply.) 

^ A. ejbFind () 


(s_: I ⑹ 


□ B. ejbLoad () 

□ C. ejbStore () 

^ D. ejbSelect() 

□ E. e jbPassivate () 






What，s true about the lifecycle of a message-driven bean? (Choose all that ap- (s?c6: 

p!y-) 

Q A. When the the onMessage method completes, the container will typi¬ 
cally call ejbRemove. 一 的 just ^oes kadk i\\t fool 

Q B. The onMessage () method can throw application exceptions. - {o v/hom ? 

口 C. Message-driven beans can run only with CMT demarcation. 

D. The getRollbackOnly () method can be called only from the 
onMessage method. 

Which statement(s) concerning message-driven bean classes are true? (s? 仏 : 兑 ;） 

(Choose all that apply.) 

Q A. They must implement, directly or indirectly, javax. jms .Message •- _仏 A1cssagcLis*tehcv* 

Q B. They must have a public constructor that takes a single argument of 
type javax • jms .Message. 

Q C. Implementing the finalize () method is allowed. - No! \v\ 

口 D. Implementing the e jbCreate () method is optional. 

E. The class must not be declared ‘final’. -* the Coirtai 


HhCV mi 


•_ 3 U I subU yo “w 


Within the deployment descriptor’s <e jb-local-ref> element, which ele- 心山 
ments are optional? (Choose all that apply.) - T 


optional? (Choose 

Q A. <local> 

^ B. <ejb-link> 

Q C. <local-home> 

^ D. 〈 description 〉 

口 E. <ejb-ref-name> 

□ F. <ejb-ref-type> 
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16 


17 


18 


What’s true about resource manager connection factories? (Choose all that 
apply.) 

^ The <res-sharing-scope 〉 deployment descriptor element is used to 
indicate whether connections to a resource manager are shareable 
across multiple EJBs in an application. 




□ 


□ 


B. The <res—sharing - scope> deployment descriptor element contains 

the <resource-ref> element. 


bddky/dvds 


C. All of a bean’s resource manager connection factory references are - eadh mus*t be 'mdividually 

declared in a single <resource-ref> element, using sfcdi-ficd 3 

<res-ref-name 〉 elements to distinguish them. <\rcsou\rdc-vc-r> 

D. By default, connections to a given resource manager are shareable 
across multiple beans in an application. 


(妒着 竹 1, 竹 W 


What’s true about security roles referenced from an EJB’s code? (Choose all 
that apply.) 

M A. In the deployment descriptor, such references are contained in the 

〈 security-role-ref> element. 

口 B. The 〈 security-role> element includes the 

<security-role-ref> element. 

^ TA7 ., . u ^ ^ , u / 1 ^ - -this is hlOT -the same as a real 

Izl C. Within the <security-role-ref> element, the <role-name> 。 G | a 

element’s value is the same as the argument for the bean’s invocation 

of the isCallerlnRole method. 

Q D. The <role-link> element is used to link two - i 七 I'mks d <s^u\rrty - vole - 代 *?> "to a 

〈 security-role-ref> elements. <scdu\r*rtY-v-olc> 

What’s true about the client’s view of security? (Choose all that apply.) s ' 




□ 


A. A transactional client cannot change its principal association within a 
transaction. 

B. A session bean’s client cannot change its principal association for the 
duration of the communication with the session object. 

C. Transactional requests within a single transaction cannot arrive from 
multiple clients. 


Q D. None of the above. 
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When programming an entity bean class which technique (s) should be 今竹 - 

AVOIDED to ensure bean portability across all EJB 2.0 containers? (Choose all 
that apply.) 

^ A. Changing a thread’s priority. 

d 


B. Using the reflection API. 
口 C. Using wrapper classes. 

口 D. Using static nested classes. 


When programming a message-driven bean class which technique (s) should 
be avoided to ensure bean portability across all EJB 2.0 containers? (Choose 
all that apply.) 

^ A. Using Swing APIs for a GUI. 

Q B. Using the ‘transient’ modifier. 


( s ? e 6： 今竹-竹 55 




C. Using native libraries. 

D. Reading file descriptors.. 


4 


What is required of the container when it passivates a stateful session bean? (s?c6: II) 

Q A. The bean’s instance state will always undergo Java programming lan¬ 
guage Serialization. 一 ••七你吵七 be similar 

Q B. It must save all of the bean’s instance field state regardless of the fields’ 
modifiers. 

C. It must save any references to the bean’s SessionContext object. 

Q D. It must save all non-null transient variables. - save variables, bu*t 

_ \j r\oi rtsti 七 hem default values. 

Which capabilities are defined in the javax. e jb .EJBLocalObject inter¬ 
face? (Choose all that apply.)? 

3^A. Remove an entity object. 

^ B. Obtain an entity object’s primary key. 

^ C. Obtain a local home interface for the entity object. 

口 D. Obtain a remote component interface for the entity object. 

口 E. Expose the methods of the javax • ejb. EntityBean interface to the 
client. 
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(sv>c6 : 

What’s true about ejbSelect methods? (Choose all that apply.) 1 

Q A. They can be exposed to the client. 

口 B. They can return only EJBObjects or EJBLocalObjects. 一 They return almos-t 

口 C. They can be invoked only by a bean in the ready state. — ^l 0) ^ood -for home biz. methods 

^ D. They must be associated with a query element in the deployment de¬ 
scriptor. 


Z4 


Which methods can NEVER be successfully invoked from a message-driven 


bean? (Choose all that apply.) 




A. isCallerlnRole() 

B. getEJBHome() 


□ 

□ 




C. getRollbackOnly() 

D. setRollbackOnly() 

E. getCallerPrincipal() 




so 


SC ⑽切 




zs 


Which role is typically responsible for adding <ejb-link> elements to an EJB’s 
deployment descriptor? 


(s ? e6: ㈣ 


口 A. bean provider 

3^ B. application assembler - oy\C. 七 ha 七 io a^o-thev- 

Q C. deployer 
口 D. container provider 
口 E. system administrator 


26 


In which of the following methods can a stateless session bean invoke the 
isCallerlnRole () method in order to perform a security check? (Choose 
all that apply.) 


(s ? c6 ： °{ 0 ) 


□ 

□ 

□ 


A. ejbCreate () 

B. ejbRemove () 

C. setSessionContext() 

D. None of the above 


- isCallcvl^RolcO t^v\ be called 
-fv-om busmess methods ojr>ly 
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Which two are typically responsible for creating ejb-jar files? (Choose two. 


A. The bean provider. 

^ B. The application assembler. 


口 C. The deployer. 

Q D. The system administrator. 


Which of the following stateless session bean container callback method (s) 
takes an argument? (Choose all that apply.) 


□ 

□ 

□ 

□ 

4 


A. ejbRemove 

B. ejbCreate 

C. ejbCreate 

D. ejbPassivate 

E. setSessionContext 




(_ :州) 




Which of these can never be called on a SessionContext interface? (Choose all 
that apply.) 


( s ? 仏 •• 刀今) 


□ A. getEJBHome() 

□ B. getEJBObject() 

^ C. getEJBTransaction() — ho sudh method : ) 
口 D. isCallerlnRole() 

□ E. getUserTransaction() 


What’s true about an entity bean’s remote component interface? (Choose all 
that apply.) 


(s^: I ⑽) 


Q A. If a client attempts to invoke a method on an entity that does not exist, a 

java, rmi .NoSuchRemoteObjectException will be thrown. 一 i 七 ’ s "oSudhObje 乙七 £ 乂乙吓七 . 

Q B. It must extend javax. e jb. E JBHome - i*t s 

^ C. Its methods must declare java, rmi. RemoteException 

□ D. It defines a remove (Handle handle) method. - TW\s is ohly ih the ho t 
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Which are true about finder methods in an entity bean’s local home interface? 
(Choose all that apply.) 

Q A. They can have any legal Java name. 一 你 us t wi 物 」rmd 


( s ? 私 •• 作) 




B. They must all declare j avax. ejb. FinderException. 

Q C. They can optionally declare j ava. rmi. RemoteException . - ho-t ih a lodal 於 1 

Q D. The findByPrimaryKey method can be overloaded. 

^ E. The findByPrimaryKey method’s return type must be the bean’s local 
component interface. 

口 F. A method called “findXXX” must have the bean’s local component 

一 i 七 dould also be a Collcdtu 


interface as its declared return type. 


\or\ 


Which are true for a message-driven bean? (Choose all that apply.) 


㈣ ： 姑-⑹ ⑺ 




A. The Deployer uses the deployment descriptor to determine whether a bean 
is intended for a Queue or a Topic. 

Q B. The class must be declared final. 




C. The class must define one e jbRemove() method. 

Q D. The class can have overloaded e jbCreate () methods. 一 s e > 

口 E. The class must define a no-argument onMessage method. — -takes a message 


Given the following subset of a deployment descriptor: 

<entity> 

<ejb-name>Payroll</ejb-name> 

<security-role-ref> 

<role-name>clerk</role-name> 

</security-role-ref> 

</entity> 

Which code snippet(s) makes a legal security check? (Choose all that apply.) 

口 A. context • isCallerlnRole (''Payroll ”）； 

B. context • isCallerlnRole (''clerk"); 

口 C. context. isCallerlnRole (''Payroll • clerk"); 

口 D. context • isCallerlnRole ( 、 'Payroll/clerk 〃）； 


(s_: W) 


668 appendix A 





appendix A final mock exam 


Which are valid local home interfaces for a stateful session bean? (Choose all (s ? ed) 
that apply.) 


口 A. public interface TestBean implements 
javax.ejb.EJBLocalHome { 

void create() throws CreateException; 

} 

Q B. public interface TestBean extends 
javax.ejb.EJBLocalHome { 

TestBeanLocal ejbCreate() throws CreateException; 


Must: 

一 ihv-oy/ 

一 lodal m-bcr-fadc bfyt 

一 st3\rt >wi*th 
一 NOT iWo^i 


^ C. public interface TestBean extends 
javax.ejb.EJBLocalHome { 

TestBeanLocal create() throws CreateException; 

} 

口 D. public interface TestBean extends 
javax.ejb.EJBLocalHome { 

TestBeanLocal create() throws CreateException , 

RemoteException; 

} 

口 E. public interface TestBean extends 
javax.ejb.EJBLocalHome { 

TestBeanLocal create() throws LocalException; 


Which methods can be called by a bean provider? (Choose all that apply.) 

^ A. remove () - -the dallbadk is cjbRcmovc 

□ B. ejbCreate () 

□ C. afterBegin () 

^ D. getCallerPrincipal() 

□ E. ejbPassivate() 


Co 山 … 伏 6a ''' c>a6kS 
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Who will typically specify whether a bean is re-entrant in the bean’s deploy¬ 
ment descriptor? 

A. The bean provider. 

Q B. The application assembler. 

Q C. The deployer. 

Q D. The system administrator. 


(s_: 糾 ) 


37 


Which statements about stateful and stateless session beans are true? 


(Choose all that apply.) 

口 A. Only stateful session beans support transactions. 


B. Only stateful session beans can be passivated. 


Q C. Only stateful session beans have a 'setSessionContext' method. .. 气， •wrxU, 

.staWcss a 

Q D. Both stateful and stateless session beans can support overloaded 

'ejbCreate' methods. 

口 E. Both stateful and stateless session beans can implement the stated' 

javax. e jb. SessionSynchronization interface. , . . Wavc state) 

0 F. Both stateful and stateless session beans can have instance variable state. v\ot 


38 


39 


Which must be included in every ejb-jar file? (Choose all that apply.) 今卵一今巧 0) 

口 A. The stub for the EJBHome interface, either directly or by reference. 

Q B. The TAR Manifest file. _ , 

^ ^ £JB Z o 


^ C. A deployment descriptor. 

Q D. TheJNDI context. 

^ E. The EJB’s home interface, either directly or by reference. 

Which method(s) are declared in the javax.ejb.EJBHome interface? (Choose 
all that apply.) 

□ A. create() 

□ B. lookup() 

□ C. getHandle() 

^ D. getHomeHandle() 

□ E. setSessionContext() 


nis is ^ 


(API dots) 
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How manyjavax.ejb.EJBLocalHome interface methods can be called without 
an exception, from a session bean client? 


¥ A. 0 

□ B. 1 

□ C. 2 

□ D. 3 

□ E. 4 


TKc o^ly method m tJBLoddlHomC is 
v-emove -that -takes a frimary key 


(sy 私 • W) 


Which of the following, if called, always have the same transaction context as a 
session bean’s business methods? (Choose all that apply.) 


(s_: » 


Q A. constructor 

□ B. setSessionContext() 
^ C. afterBegin() 


□ D. afterCompletion () 一七 vahsa^tio 灼 is ow 
^ E. beforeCompletion() 


Given a stateful session bean with container-managed transaction demarcation, (s^j>c6 : 
from which methods can you access another bean? (Choose all that apply.) 


□ 

□ 


A. setSessionContext() 

B. ejbCreate () 

C. afterBegin () 

D. beforeCompletion () 

E. afterCompletion() 


sc-tScssio^Coi^-tc'X.'t 
a-f-tcv-Comflctio^ hav/e 

NO 你⑸灼 m—l 七乂 dojvtwb 


Which deployment descriptor element(s) can optionally specify cascade-delete 
functionality? (Choose all that apply.) 


□ 

□ 

□ 


A. <ejb-relation> 

B. <abstract-schema - name> 

C. <ejb-relationship-role> 

D. <relationship-role-source> 


(s ? e6: ㈣) 
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What’s true about cascade-delete? (Choose all that apply.) 

口 A. It is declared in the e jbRemove () method. 

Q B. When a cascade-delete enabled bean is deleted, it causes 
beans with relationships to it to be automatically deleted 

Q C. It can be specified for one-to-one, one-to-many, or many-to-many rel^o*t -for ma 竹 y 一 "to 一你 any 
tionships. 

J 

QlI D. A cascade-delete enabled bean is automatically removed when any 
“multiplicity of one” bean with which it is related is removed. 


(s_: I 如 

一 dasdadc-dclctc says “delete" 
all of the ME i-f w\y is vemoved 

too. 


46 


Which method(s) from the EntityContext interface can be invoked, regardless 
of transaction context? (Choose all that apply.) 

^ A. getEJBHome() 
b. getEJBObject() 

□ C. setRollbackOnly() 

□ D. getRollbackOnly() 


(Choose all that apply.) 

- you use s domfouir\d key 


What’s true about an entity bean’s primar 
Q A. Primary key fields must be cmp-fields 

B. Setter methods for fields associated with a primary key must not be 
exposed through a client view. 

^ C. If two entity objects have the same home and the same primary key, 
they are considered identical. 

口 D. The getPrimaryKey () method can be invoked on references to only 
remote home interfaces, not local home interfaces. 

Which interface (s) are used by the bean provider to perform BMT demarca¬ 
tion? (Choose all that apply.) 

口 A. javax.transaction.Transaction 

^ B. javax.transaction.UserTransaction 

口 C. javax•transaction.Synchronization 

Q D. javax.transaction.Transact!onManager 


I®。) 


㈣:⑽ _ 




m) 
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Which of the following are legal EJB QL queries? (Choose all that apply.) 

□ A. SELECT c 一 weds Object U) or d 

FROM Customer c 

□ B. SELECT (OBJECT) c.name ^ a || ^ ^ f)BJECT(d) ov 

FROM Customer c d.^amc (see air>sy/cv-s V ahd E) 

□ C. SELECT OBJECT c ^ mU st have d FROM, S^d (t) 

WHERE Customer c 

Sf D. SELECT OBJECT (c) 

FROM Customer c 

^ E. SELECT c.name 

FROM Customer c 




Which are true about transactions in EJB 2.0? (Choose all that apply.) 

Q A. Only one database can be updated within a single transaction. 

Q B. Entity beans with BMT demarcation must use the setStatus method 




instead of the setRollbackOnly method. 


C. Entity beans with BMT demarcation must use the getStatus method 
instead of the getRollbackOnly method. 

Q D. BMT demarcation should be used when beans access resource 


㈣ 6: m 


一 This y/ould clmima'tc a key 

BJB 2- 0 Jpcaiuv-c o( 

dis-tv-ibu-bcd *brahsa^bo 吣 




ers that do not support transactions. 




E. The 4 SessionSynchronization 5 interface can be used only by stateful 
session beans. 


To ensure bean portability, which transaction attributes should be used on the 
business methods in the component interface of an entity bean using CMP? 
(Choose all that apply.) 


口 A. NotSupported 
5^ B. Required 
口 C. Supports 
^ D. RequiresNew 
^ E. Mandatory 
Q F. Never 




拟 ) 
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Which of the following exceptions would cause a bean to be discarded by the 
container? (Choose all that apply.) 


( s ? 私: m 讲) 


□ A. javax. e jb. Ob jectNotFoundException The o-thevs arc v-cdovcraklc 

□ B. javax. ejb. CreateException affiliation 

^ C. javax. e jb.NoSuchEntityException 
Q D. javax• ejb• FinderException 
口 E. javax. ejb. RemoveException 



In which cases should the container log an exception thrown by a business 

method of a CMT demarcated bean? (Choose all that apply.) 

ST A. If the method runs with an unspecified transaction context and throws 
a system exception. 

Q B. If the method runs with an unspecified transaction context and throws 
an application exception. 

^ C. If the method runs with a Re quire sNew context and throws a system 
exception. 

^ D. If the method runs with a Required context and throws a system excep¬ 
tion. 


( s 〜 •讣) 


一 system 

alv/ays lo^cd 


口 E. If the method runs with a RequiresNew context and throws an applica¬ 
tion exception. 

Q F. If the method runs with a Required context and throws an application 
exception. 


53 


Which session bean component interface method (s) can be called successfully, 
by a local client? (Choose all that apply.) 

13 A. remove () 

□ B. getHandle () 一 lodal vicv/S Ao ^ havc hahdleS 

^ C. is Identical () 

□ D. getEJBHome () 
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In what scenario(s) can a bean’s business method call the isCallerlnRole () 
method of the SessionContext interface? (Choose all that apply.) 

0 A. A stateful session bean with container-managed transaction deman ^ esy / 七 matter here 
tion. 

B. A stateless session bean with container-managed transaction demarca¬ 
tion. 

^ C. A stateful session bean with bean-managed transaction demarcation. 

D. A stateless session bean with bean-managed transaction demarcation. 

Q E. None of the above. 

I ;。） 

When creating an entity bean using container-managed persistence, which can 
be accessed through the bean’s remote component interface? (Choose all that 
apply.) 

Q A. Accessor methods for the relationship fields. 

口 B. The local interface of the entity bean. 

^ C. The bean’s business methods. 

Q D. The collection classes used for container-managed relationships. 

^ E. Accessor methods for the persistent fields. , \^a\, just a ^ood d 


Given the container-managed, one-to-one, bidirectional relationship: 


(s_: I ⑽ 


Foo 


< - > Bar 


And the object relations: 

fl <——> bl 
f2 <——> b2 

Which boolean expression will be true after the following code runs: 


b2 . setFoo (bl.getFoo ()); 

(Choose all that apply.) 

□ A. f1•getBar() == null 

□ B. b2.getFoo() == null 
C. f2.getBar() == null 

Q D. none of the above 


bz -took bl's poo, he reflated his ovm 
\ool - Y/I*th -Pool. So v\o>n, -PooZ y\o bav". 
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What’s true about an entity bean’s identity? (Choose all that apply.) 


A. 


□ B. 




If two entity object references are compared using the == operator, the 
container provider is not required to produce consistent results. 


If two entity object references are compared using the equals () 
method, the container will return true if the two entity objects have the 
same primary key. 一 ⑽七 o^ara^ittd 

C. If two entity object references are compared using the isldentical () 
method, the container will return true if the two entity objects have the 
same primary key. 

Q D. None of the above statements are true. 


58 


Given CMP beans CustomerBean, OrderBean, and LineltemsBean with the 
following relationships: 

CustomerBean (1) < — > OrderBean (n) 

OrderBean (1) < — > LineltemsBean (n) 


Which will return a set of customers that have orders? (Choose all that apply.) 

□ A. SELECT Customer 一 OBJECT ov- fath 

FROM Order 

□ B. SELECT DISTINCT Customer 一 OBJECT ov yai\\ 

FROM Order 


口 C. SELECT o.custnum 

FROM Order o, Customer c 
WHERE c.custnum = o.custnum 


□ D. SELECT OBJECT (c) 

FROM Customer c, Order o 




WHERE c.custnum = o.custnum 
E. SELECT DISTINCT OBJECT (c) 


- 竹。七 a Cus-tomcv- -type 


- docs^-t ^uav-a^-bcc you v/o^-b 
dufl'ida-tcs 


FROM Customer c, Order o 


WHERE c.custnum = o.custnum 
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Given: 

( s _: 扣肩) 

Method-1 (Tx-l) --> Method-2 (Tx-1) > Method-3 (Tx-1) 

\--> Method-4 (Tx-2) 


If the calling method is on the left side of an arrow, and the called method on 
the right, which set of transaction attributes will support the transaction scope 
specified? (Choose all that apply.) 


□ 

A. 

Ml = 

: Never 



M2 = 

Supports 



M3 = 

Required 

aT 


M4 = 

RequiresNew 

B. 

Ml = 

Required 



M2 = 

Supports 



M3 = 

Mandatory 



M4 = 

RequiresNew 

□ 

C. 

Ml = 

RequiresNew 



M2 = 

RequiresNew 



M3 = 

Supports 



M4 = 

RequiresNew 

□ 

D. 

Ml = 

Required 



M2 = 

Mandatory 



M3 = 

Supports 



M4 = 

Supports 


一 method 午 ^ l . 

—e 二? “Z L , 怒 OJ 。 士 “吻 


一 10 如 d I 弓 


如 Excluded 


Given the EJB QL expression: 

p.discount NOT BETWEEN 10 AND 15 

Which expression is equivalent? 

^ A. p.discount < 10 OR p.discount > 15 

□ B. p.discount <= 10 OR p.discount > 15 

□ C. p.discount < 10 OR p.discount >= 15 

□ D. p.discount <= 10 OR p.discount >= 15 


(s_: 
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When a business method in an entity bean calls the getRollbackOnly () 
method, which transaction attribute settings could cause the container to 
throw an exception? (Choose all that apply.) 








A. NotSupported 


Q B. Required 

^ C. Supports 一 because 你吵七⑽七 be o 从 

Q D. RequiresNew 


□ 


E. Mandatory 

F. Never 


62 


Which of the following is performed by the container if a message-driven bean 


does not complete its transaction before the end of the onMessage() method? 
(Choose all that apply.) 


^ A. Log an application error. 


4 


B. Roll back the started transaction. 

C. Discard the instance of the bean. 


㈣ :糾 


Q D. Throw an exception. — y/hom? 


63 
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From which class (es) can application exceptions extend? 


(Choose all that ap - is ? 私 




p!y-) 

^ A. 

□ B. 

□ C. 
^ D. 


java.lang.Exception 

j ava. lang. RuntimeException - mUS t cMttktd 

j ava. rmi. RemoteException - just CBv\ *t do 七 "Ijiiough it |S a 

的…》七 s OtBv\ Lav/ 

javax.ejb.CreateException 


What’s true about application exceptions? (Choose all that apply.) 
Q A. They are intended to be handled by the system administrator. 
口 B. They should report system level problems. 


□ 

□ 


C. They cause automatic marking of transactions for rollback. 

D. They must not extend j ava. lang. RuntimeException 

E. They may extend java. rmi . Remo teExcept ion 一 j\IQ 


Csyct ： 讯-挪 


They avc b> be 

Kair>alcd by {\\t d ’ 心七 
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Which cases can cause a session bean instance to be destroyed without the 
container calling e jbRemove () ? (Choose all that apply.) 


(s_ H) 


□ A. 
B. 

af c. 


A transaction is rolled back on a stateful session bean with container- 
managed transaction demarcation. 

A system exception is thrown from a business method. 

An inactive client is timed out while the bean is in a passivated state. 


口 D. The client invokes the remove method while the bean is in a transac- 
U on . — di ⑶七 yts bc3h survives 


Which deployment descriptor element(s) are used to specify a Collection 
interface? (Choose all that apply.) 

Q A. <ejb-name> 

Q B. <cmr-field> 


□ C. <ejb - relation 〉 


D. <cmr-field-type> ^ 0 ^oLt ， o^ 
口 E. <abstract-schema-name> 


-for _1 切 lid’rty, "to *mdida*tc 


(s 〜 • 桃 ) 


If a bean catches a checked exception, from which it cannot recover, what 
should it do? (Choose all that apply.) 


(s? 仏 : 奶 ) 


□ A. If the client is remote, throw a java.rmi.RemoteException. _ 3 bean mus-t NE\/ER 

□ B. Print a stack trace. O^ly iht 

Co»r\-t3»^CV- d 扣 do rt. 

^ C. Regardless of the client, throw a javax. ejb. EJBException. 

口 D. Regardless of the client, propagate the same exception to the contain¬ 


er. 


Which are requirements for a CMP entity bean class? (Choose all that apply.) 

A. All ejbSelect () methods must be declared as abstract.. 

Q B. The class must NOT define an ejbCreate method. 

口 C. The ejbPostCreate methods are implemented by the container. 

口 D. Helper methods must NOT be implemented in the bean class. 

E. Methods starting with ‘e jbFind’ must not be implemented. 


(s ? e6 ： 唞 - 鬥 1) 
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Which are valid deployment descriptor segment(s) to define a cmr-field? 
(Choose all that apply.) 


(_• •拟声 


Q A. <ejb-relationship-role> 

<!-- assume mandatory ejb—relationship-role elements 
inserted here —— > 


<cmr-field> 

<cmr-field- type>j ava. util. Collection</cmr-field-type> 
</cmr-field> 


</ejb-relationship-role> 

^ B. <ejb-relationship - role> 

<!-- assume mandatory ejb-relationship-role elements 
inserted here --> 


<cmr-field> 

<cmr-field-name>l ine I tems</cmr-field-name> 
<cmr-field-type〉j ava. util. Collection</onr-field-type> 
</cmr-field 〉 

<ejb-relationship-role> 

口 C. <relationship-role-source> 

<!—— assume mandatory relationship-role-source ele¬ 
ments inserted here —— > 


<cmr-field> 

<cmr-field-type〉j ava. util. Collection</anr-field-type> 
</cmr - field 〉 


- and m 
v-olc source, as offosed 
■to vole 


</relationship-role-source> 
Q D. <relationship-role-source> 


<!-- assume mandatory relationship-role-source ele¬ 
ments inserted here —— > 


<cmr-field> 

<cmr -field- name>l ine I tems</cmr -field - name> 




m 3 souy ■仪 


<cmr-field- type>j ava. util. Collection</cmr-field-type> 
</cmr-field> 

</relationship-role-source> 
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What’s true about a remote client’s view of exceptions received from an entity 
bean? (Choose all that apply.) 

Q A. If the container marks a transaction for rollback, the container will 

always issue a javax. transaction. TransactionRolledbackExce 
ption exception. 

^ B. If the client receives a javax • transaction. TransactionRolled 
BackException, the container guarantees that that transaction will 
never commit. 


- o^ly i-f wallers 
-tv-ahsadtio^ was v-ollcd 
ba^k (as offosed -to 
suspended) 


zf c. 


A javax• transaction. TransactionRequiredException excep¬ 
tion, informs the client that the bean needed to be called within the 
context of a transaction. 


一 W\{\\ 七 he 

Ma^da*tov-y i% atbrilou 七 e 


Q D. If the container discovers that a requested bean no longer exists, it will 
always throw the javax. e jb .NoSuchObjectEntityException. 
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Tliis isn’t goocttye 

Bring your brain over to 
wickedlysmart.com 


good luck 


Don’t you know there's more on the 
wickedlysmart.com website? you’ll find some 
code, some more mock exam questions, and 
maybe even our favorite martini recipe. 

And if you’re going to take the exam be sure to drop by 
javaranch.com and spend some time in the 5CBCD 
study forum. Folks there are just so damn 
friendly ifll make you want to throw up. 


And don’t forget to write and tell us 
when you pass the exam! 

Ikickedbutt@wickedlysmart.com 

Wei! have a drink in your honor. 


\ 
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B 
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beanness 188, 191, 196 
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bean inheritance 186 
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overview 98 
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Bean Provider 26 
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lookup 116 
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local 145 
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CMP 302 
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chapter 9: transactions 516 
commit 471,473 
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component interface 87, 133, 234, 271, 272 
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implementing in a session bean 183 
setSessionContextO 183 


688 


the index 


Container responsibilities 
exceptions 546 
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create methods 159, 181 
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entity beans 329 
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D 

database 301 

database to entity mapping 400 
DataSource 602, 610 
dead bean 284 

entity vs. instance death 285 
declarative security 572 
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DELETE 265 

deploy-time customization 602, 618 
Deployer 27 
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583 
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<ejb-link> 615 
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E 
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400 
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java.rmi.Remote 


II no methods declared 


javax.ejb.EJBHome 


getEJBMetaData() 
getHomeHandle() 
remove(Handle h) 
remove(Object PK) 


javax.ejb.EJBObject 


getEJBHome() 
getHandle() 
getPrimaryKey() 
isldentical(EJBObject o) 
remove() 


javax.ejb.EJBLocalHome javax.ejb.EJBLocalObject 


remove(Object PK) 


getEJBLocalHome() 

getPrimaryKey() 

isldentical(EJBLocalObject 

o) 
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Interface summary 


javax.transaction.UserTransaction 



begin() 

commit() 

getStatus() 

rollback() 

setRollbackOnly() 

setTransactionTimeout(int seconds) 


…丄一 丁一 tod :. 


javax.ejb.SessionSynchronization 

afterBegin() 

afterCompletion( boolean committed) 
beforeCompletion() 


javax.jms.MessageListener 


onMessage(Message message) 

















